fix: prevent catalog scan use-after-free#501
Merged
staticlibs merged 2 commits intoJul 8, 2026
Merged
Conversation
Member
|
Hi, thanks for the PR! I wonder whether the |
d8befe0 to
f8537b8
Compare
Contributor
Author
Thanks for catching this! |
staticlibs
added a commit
to staticlibs/duckdb-postgres
that referenced
this pull request
Jul 8, 2026
This is a backport of the PR duckdb#501 to v1.5-variegata stable branch. Resolves duckdb#502 `PostgresCatalogSet::Scan` hands its callback a bare `CatalogEntry&` without pinning it into the calling transaction first. `GetEntry` and `CreateEntry` both keep the underlying `shared_ptr<CatalogEntry>` alive in `PostgresTransaction::referenced_entries` for the rest of the transaction. `Scan` does not. If `pg_clear_cache` runs after a `Scan` but before every reference handed out by that `Scan` is done being used, `ClearEntries` drops the `shared_ptr` for those entries and destroys them. Anything still holding a reference from the earlier `Scan` is then reading freed memory; i.e., funcs from Duckdb core like `duckdb_tables()` or `duckdb_vies()` Pinning every entry into the calling transaction inside `Scan`'s existing lock scope, the same way `GetEntry` and `CreateEntry` already do: ```cpp for (auto &entry : entries) { transaction.ReferenceEntry(entry.second); callback(*entry.second); } ``` `ReferenceEntry`/`referenced_entries` is already the established solution for this exact problem. `Scan` just wasn't using it yet
staticlibs
added a commit
that referenced
this pull request
Jul 8, 2026
This is a backport of the PR #501 to v1.5-variegata stable branch. Resolves #502 `PostgresCatalogSet::Scan` hands its callback a bare `CatalogEntry&` without pinning it into the calling transaction first. `GetEntry` and `CreateEntry` both keep the underlying `shared_ptr<CatalogEntry>` alive in `PostgresTransaction::referenced_entries` for the rest of the transaction. `Scan` does not. If `pg_clear_cache` runs after a `Scan` but before every reference handed out by that `Scan` is done being used, `ClearEntries` drops the `shared_ptr` for those entries and destroys them. Anything still holding a reference from the earlier `Scan` is then reading freed memory; i.e., funcs from Duckdb core like `duckdb_tables()` or `duckdb_vies()` Pinning every entry into the calling transaction inside `Scan`'s existing lock scope, the same way `GetEntry` and `CreateEntry` already do: ```cpp for (auto &entry : entries) { transaction.ReferenceEntry(entry.second); callback(*entry.second); } ``` `ReferenceEntry`/`referenced_entries` is already the established solution for this exact problem. `Scan` just wasn't using it yet
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #502
Problem
PostgresCatalogSet::Scanhands its callback a bareCatalogEntry&without pinning it into the calling transaction first.GetEntryandCreateEntryboth keep the underlyingshared_ptr<CatalogEntry>alive inPostgresTransaction::referenced_entriesfor the rest of the transaction.Scandoes not.If
pg_clear_cacheruns after aScanbut before every reference handed out by thatScanis done being used,ClearEntriesdrops theshared_ptrfor those entries and destroys them. Anything still holding a reference from the earlierScanis then reading freed memory; i.e., funcs from Duckdb core likeduckdb_tables()orduckdb_vies()Fix
Pinning every entry into the calling transaction inside
Scan's existing lock scope, the same wayGetEntryandCreateEntryalready do:ReferenceEntry/referenced_entriesis already the established solution for this exact problem.Scanjust wasn't using it yet