Skip to content

Cherry-pick CVE-2024-7348 fix #1614

Open
reshke wants to merge 2 commits intoapache:mainfrom
reshke:wjdejidew
Open

Cherry-pick CVE-2024-7348 fix #1614
reshke wants to merge 2 commits intoapache:mainfrom
reshke:wjdejidew

Conversation

@reshke
Copy link
Contributor

@reshke reshke commented Mar 12, 2026

CVE fix commit message:

Restrict accesses to non-system views and foreign tables during pg_dump.
When pg_dump retrieves the list of database objects and performs the
data dump, there was possibility that objects are replaced with others
of the same name, such as views, and access them. This vulnerability
could result in code execution with superuser privileges during the
pg_dump process.

This issue can arise when dumping data of sequences, foreign
tables (only 13 or later), or tables registered with a WHERE clause in
the extension configuration table.

To address this, pg_dump now utilizes the newly introduced
restrict_nonsystem_relation_kind GUC parameter to restrict the
accesses to non-system views and foreign tables during the dump
process. This new GUC parameter is added to back branches too, but
these changes do not require cluster recreation.

Back-patch to all supported branches.

Reviewed-by: Noah Misch
Security: CVE-2024-7348
Backpatch-through: 12

====================================================================================
For clean rebase, auxiliary commit included:

Prevent pgstats from getting confused when relkind of a relation changes

When the relkind of a relache entry changes, because a table is converted into a view, pgstats can get confused in 15+, leading to crashes or assertion failures.

For HEAD, Tom fixed this in b23cd18, by removing support for converting a table to a view, removing the source of the inconsistency. This commit just adds an assertion that a relcache entry's relkind does not change, just in case we end up with another case of that in the future. As there's no cases of changing relkind anymore, we can't add a test that that's handled correctly.

For 15, fix the problem by not maintaining the association with the old pgstat entry when the relkind changes during a relcache invalidation processing. In that case the pgstat entry needs to be unlinked first, to avoid PgStat_TableStatus->relation getting out of sync. Also add a test reproducing the issues.

No known problem exists in 11-14, so just add the test there.

Reported-by: vignesh C vignesh21@gmail.com
Author: Andres Freund andres@anarazel.de
Reviewed-by: Tom Lane tgl@sss.pgh.pa.us
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com
Backpatch: 15-

Fixes #ISSUE_Number

What does this PR do?

Type of Change

  • Bug fix (non-breaking change)
  • New feature (non-breaking change)
  • Breaking change (fix or feature with breaking changes)
  • Documentation update

Breaking Changes

Test Plan

  • Unit tests added/updated
  • Integration tests added/updated
  • Passed make installcheck
  • Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

Additional Context

CI Skip Instructions


@reshke
Copy link
Contributor Author

reshke commented Mar 12, 2026

First commit is just another auxiliary commit, for https://git.postgresql.org/cgit/postgresql.git/commit/?h=REL_14_STABLE&id=72ef1675e2bc502b31854b1c31ccf22fde7cde47 clean backport

@reshke reshke force-pushed the wjdejidew branch 2 times, most recently from 30c0cda to fa3f8aa Compare March 12, 2026 15:15
When the relkind of a relache entry changes, because a table is converted into
a view, pgstats can get confused in 15+, leading to crashes or assertion
failures.

For HEAD, Tom fixed this in b23cd18, by removing support for converting a
table to a view, removing the source of the inconsistency. This commit just
adds an assertion that a relcache entry's relkind does not change, just in
case we end up with another case of that in the future. As there's no cases of
changing relkind anymore, we can't add a test that that's handled correctly.

For 15, fix the problem by not maintaining the association with the old pgstat
entry when the relkind changes during a relcache invalidation processing. In
that case the pgstat entry needs to be unlinked first, to avoid
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing
the issues.

No known problem exists in 11-14, so just add the test there.

Reported-by: vignesh C <vignesh21@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com
Backpatch: 15-
@reshke reshke changed the title Prevent pgstats from getting confused when relkind of a relation changes Cherry-pick CVE-2024-7348 fix Mar 12, 2026
@reshke reshke added cherry-pick cherry-pick upstream commts type: Security Vulnerability disclosure or Fixing security issue labels Mar 12, 2026
When pg_dump retrieves the list of database objects and performs the
data dump, there was possibility that objects are replaced with others
of the same name, such as views, and access them. This vulnerability
could result in code execution with superuser privileges during the
pg_dump process.

This issue can arise when dumping data of sequences, foreign
tables (only 13 or later), or tables registered with a WHERE clause in
the extension configuration table.

To address this, pg_dump now utilizes the newly introduced
restrict_nonsystem_relation_kind GUC parameter to restrict the
accesses to non-system views and foreign tables during the dump
process. This new GUC parameter is added to back branches too, but
these changes do not require cluster recreation.

Back-patch to all supported branches.

Reviewed-by: Noah Misch
Security: CVE-2024-7348
Backpatch-through: 12
@reshke
Copy link
Contributor Author

reshke commented Mar 13, 2026

As discussed, cherry-picking for main branch is done only for CVE fix. Additionally, in this particular case, an auxiliary commit also picked, simplifying rebase

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherry-pick cherry-pick upstream commts type: Security Vulnerability disclosure or Fixing security issue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants