agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Harden tsquery code against overflows. 6+ messages / 1 participants [nested] [flat]
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/90649b6f846c7593f0f57b2b821b8d8eb1e18693 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3b2238fbe9b9cc95f026fd4129804a72d0c22151 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dddc8a69ff8bde575ce950e9074439ccfd975336 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8e87bd4731d7d285b1d06bead0e74058bdb82a69 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/84b6a7a06197600e8c9ea4f542066602c80fae4b Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Harden tsquery code against overflows. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Harden tsquery code against overflows. The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4f8b37b6bf0f6b038e26d1d75ce6407e1a56aa9b Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/tsquery_util.c | 13 ++++++++++--- src/include/tsearch/ts_type.h | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-08-10 13:41 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Harden tsquery code against overflows. 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