agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Empty search_path in amcheck. 5+ messages / 1 participants [nested] [flat]
* pgsql: Empty search_path in amcheck. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 5+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution. This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <violin0613@tju.edu.cn> Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/0fbf785b13e6d8db093adc98fcbf8fd6d1642b80 Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- contrib/amcheck/verify_common.c | 1 + src/backend/utils/init/usercontext.c | 6 ++++++ 4 files changed, 37 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Empty search_path in amcheck. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 5+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution. This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <violin0613@tju.edu.cn> Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/557cc7186435c7e228c8e4074254a84d1e845790 Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- contrib/amcheck/verify_common.c | 1 + src/backend/utils/init/usercontext.c | 6 ++++++ 4 files changed, 37 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Empty search_path in amcheck. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 5+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution. This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <violin0613@tju.edu.cn> Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0a61fcde03257739d59d9b96e4c77f6c65e070e3 Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- contrib/amcheck/verify_common.c | 1 + src/backend/utils/init/usercontext.c | 6 ++++++ 4 files changed, 37 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Empty search_path in amcheck. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 5+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution. This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <violin0613@tju.edu.cn> Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e41c72aff0399dd46f3c4f2f7ee242e99ecf0e32 Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- src/backend/utils/init/usercontext.c | 6 ++++++ 3 files changed, 36 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Empty search_path in amcheck. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 5+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution. This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <violin0613@tju.edu.cn> Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2cc14731825ec94017a3717e510f1f6780160c8a Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- contrib/amcheck/verify_nbtree.c | 2 ++ src/backend/utils/init/usercontext.c | 6 ++++++ 4 files changed, 38 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-08-10 13:41 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-10 13:41 pgsql: Empty search_path in amcheck. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Empty search_path in amcheck. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Empty search_path in amcheck. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Empty search_path in amcheck. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Empty search_path in amcheck. Noah Misch <noah@leadboat.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox