public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Harden _int_matchsel() against being attached to the wrong opera 6+ messages / 1 participants [nested] [flat]
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b69af3dda26104b54d4e728c6946edcc79a8ac61 Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 73 ++++++++++++++++++++++ src/backend/commands/extension.c | 129 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 220 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8ebdf41c262ccd86407ca684aab3113bdbcf2c66 Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 73 ++++++++++++++++++++++ src/backend/commands/extension.c | 129 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 220 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c0887b39dc5440babd935ab9cab84fbf80454389 Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 73 ++++++++++++++++++++++ src/backend/commands/extension.c | 130 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 221 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dd3ad2a4d7e8c7bcc34e6574787744b3524d28be Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 72 ++++++++++++++++++++++ src/backend/commands/extension.c | 130 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 220 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/deb464a40852b381320264a2249b6f7641227db0 Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 73 ++++++++++++++++++++++ src/backend/commands/extension.c | 130 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 221 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden _int_matchsel() against being attached to the wrong opera @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Harden _int_matchsel() against being attached to the wrong operator. While the preceding commit prevented such attachments from occurring in future, this one aims to prevent further abuse of any already- created operator that exposes _int_matchsel to the wrong data types. (No other contrib module has a vulnerable selectivity estimator.) We need only check that the Const we've found in the query is indeed of the type we expect (query_int), but there's a difficulty: as an extension type, query_int doesn't have a fixed OID that we could hard-code into the estimator. Therefore, the bulk of this patch consists of infrastructure to let an extension function securely look up the OID of a datatype belonging to the same extension. (Extension authors have requested such functionality before, so we anticipate that this code will have additional non-security uses, and may soon be extended to allow looking up other kinds of SQL objects.) This is done by first finding the extension that owns the calling function (there can be only one), and then thumbing through the objects owned by that extension to find a type that has the desired name. This is relatively expensive, especially for large extensions, so a simple cache is put in front of these lookups. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7e82d9a04d0fba0678f4349f23b03bbdf83193f7 Modified Files -------------- contrib/intarray/_int_selfuncs.c | 14 ++++- src/backend/catalog/pg_depend.c | 73 ++++++++++++++++++++++ src/backend/commands/extension.c | 130 +++++++++++++++++++++++++++++++++++++++ src/include/catalog/dependency.h | 2 + src/include/commands/extension.h | 2 + src/tools/pgindent/typedefs.list | 1 + 6 files changed, 221 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-09 15:15 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Harden _int_matchsel() against being attached to the wrong opera Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox