| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | kuznetsovam(at)altlinux(dot)org |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, egori(at)altlinux(dot)org, nickel(at)altlinux(dot)org |
| Subject: | Re: [PATCH] Check for TupleTableSlot nullness before dereferencing |
| Date: | 2024-10-03 09:48:37 |
| Message-ID: | FDD95AB2-17BF-4C52-A8A9-682115FB4684@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 3 Oct 2024, at 09:47, Alexander Kuznetsov <kuznetsovam(at)altlinux(dot)org> wrote:
>
> Hello everyone,
>
> I'd like to propose adding check for nullness of
> TupleTableSlot before dereferencing it in /src/backend/executor/nodeAgg.c
>
> It is done in the same manner other TupleTableSlots are checked,
> but was probably left unseen because slot1 and slot2 variables
> can be swapped during function execution.
From a quick reading we can only reach there after evaluating an expression, so
can it really be null though? This code hasn't changed all that much since
2009, if there was a reachable segfault on a null pointer deref I have a
feeling we'd heard about it by now so some extra care seems warranted to ensure
it's not a static analyzer false positive.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2024-10-03 10:15:38 | RE: long-standing data loss bug in initial sync of logical replication |
| Previous Message | Fujii Masao | 2024-10-03 09:46:25 | Re: Using per-transaction memory contexts for storing decoded tuples |