Re: Use-after-free in expand_partitioned_rtentry
Bernd Reiß <bd_reiss@gmx.at>
From: Bernd Reiß <bd_reiss@gmx.at>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-08-29T11:45:52Z
Lists: 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
Commits
-
Fix possible use after free in expand_partitioned_rtentry()
- 8286bce0a06a 15.15 landed
- f0fe1da50998 16.11 landed
- ed394c4bdf12 17.7 landed
- 4aea5589106b 18.0 landed
- da9f9f75e5ce 19 (unreleased) landed
-
Avoid failure to open dropped detached partition
- 52f3de874bbe 18.0 cited