Re: Use-after-free in expand_partitioned_rtentry - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use-after-free in expand_partitioned_rtentry
Date
Msg-id CAApHDvpjxuDzn6=umz31QC=e_WTZJR98HzF+j-Yvd+b8M0KQvA@mail.gmail.com
Whole thread Raw
In response to Use-after-free in expand_partitioned_rtentry  (Bernd Reiß <bd_reiss@gmx.at>)
Responses Re: Use-after-free in expand_partitioned_rtentry
List pgsql-hackers
On Fri, 29 Aug 2025 at 23:16, Bernd Reiß <bd_reiss@gmx.at> wrote:
> there seems to be a case of use-after-free in the function
> expand_partitioned_rtentry (src/backend/optimizer/util/inherit.c). In
> the NULL-check introduced to handle concurrently detached and dropped
> partitions (see [1]), the partition gets removed from the set of live
> partitions using bms_del_member but the returned Bitmapset is only
> assigned to relinfo->live_parts and not to the local variable live_parts
> being used in the while condition in Line 381. However, if the partition
> actually is the last one in the set, bms_del_member performs a pfree on
> the Bitmapset and returns NULL.  relinfo->live_parts is set to NULL but
> the local variable live_parts still points to the old address.
> Therefore, it becomes a dangling pointer, leading to a use-after-free
> when accessed by bms_next_member.

Yeah. Agreed.

I did suspect this code might have predated 00b41463c (from 2023), and
might have been ok when it was written, but that's not the case as it
was only added in 52f3de874 (in 2024).

Your fix looks good to me. I do prefer getting rid of the variable
rather than adding the additional assignment as it reduces the chance
of future omissions.

David



pgsql-hackers by date:

Previous
From: Bernd Reiß
Date:
Subject: Use-after-free in expand_partitioned_rtentry
Next
From: Bernd Reiß
Date:
Subject: Re: Use-after-free in expand_partitioned_rtentry