agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Guard against overflow in "left" fields of query_int and ltxtque 6+ messages / 1 participants [nested] [flat]
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/43451a7a2b3305571e7f8ed56d053e97acca1d1d Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 82 +++++++++++++++++++++++++++++--------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 + contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 75 ++++++++++++++++++++++++++-------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 133 insertions(+), 35 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c5790ec4fd9a6ae9e0bf322a06ee9de2eedf3e11 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 82 +++++++++++++++++++++++++++++--------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 + contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 75 ++++++++++++++++++++++++++-------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 133 insertions(+), 35 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c4d04cc4810303427d2f6fcf914bb856af32cc52 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 82 +++++++++++++++++++++++++++++--------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 + contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 75 ++++++++++++++++++++++++++-------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 133 insertions(+), 35 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5c1069c35b49227f955735ea5f2a2ee1c9c48a63 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 82 +++++++++++++++++++++++++++++--------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 + contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 75 ++++++++++++++++++++++++++-------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 133 insertions(+), 35 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/84a9f2641d8c69503505c3f96d9d89ab625c5dec Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 60 ++++++++++++++++++++++++++++++-------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 ++ contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 51 +++++++++++++++++++++++++------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 100 insertions(+), 22 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against overflow in "left" fields of query_int and ltxtque @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against overflow in "left" fields of query_int and ltxtquery. contrib/intarray's query_int type uses an int16 field to hold the offset from a binary operator node to its left operand. However, it allows the number of nodes to be as much as will fit in MaxAllocSize, so there is a risk of overflowing int16 depending on the precise shape of the tree. Simple right-associative cases like "a | b | c | ..." work fine, so we should not solve this by restricting the overall number of nodes. Instead add a direct test of whether each individual offset is too large. contrib/ltree's ltxtquery type uses essentially the same logic and has the same 16-bit restriction. (The core backend's tsquery.c has a variant of this logic too, but in that case the target field is 32 bits, so it is okay so long as varlena datums are restricted to 1GB.) In v16 and up, these types support soft error reporting, so we have to complicate the recursive findoprnd function's API a bit to allow the complaint to be reported softly. v14/v15 don't need that. Undocumented and overcomplicated code like this makes my head hurt, so add some comments and simplify while at it. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0747025259d6219e215dc1ff7924eabdc39c1749 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- contrib/intarray/_int_bool.c | 60 ++++++++++++++++++++++++++++++-------- contrib/intarray/expected/_int.out | 3 ++ contrib/intarray/sql/_int.sql | 2 ++ contrib/ltree/expected/ltree.out | 3 ++ contrib/ltree/ltxtquery_io.c | 51 +++++++++++++++++++++++++------- contrib/ltree/sql/ltree.sql | 3 ++ 6 files changed, 100 insertions(+), 22 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-11 12:19 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against overflow in "left" fields of query_int and ltxtque 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