Re: Use-after-free in expand_partitioned_rtentry
От | Bernd Reiß |
---|---|
Тема | Re: Use-after-free in expand_partitioned_rtentry |
Дата | |
Msg-id | e179502a-fdb6-4fab-8245-731fabc5afdb@gmx.at обсуждение исходный текст |
Ответ на | Re: Use-after-free in expand_partitioned_rtentry (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Use-after-free in expand_partitioned_rtentry
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: