Thanks for the quick response and the review.
This is admittedly a pretty remote edge case, but still, better safe
than sorry.
Bernd
On 8/29/25 1:29 PM, David Rowley wrote:
> 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
