ltree: Fix overflows with lquery parsing The lquery parser in contrib/ltree/ had two overflow problems: - A single lquery level with many OR-separated variants (e.g., 'label1|label2|...'), could cause an overflow of totallen, this being stored as a uint16, meaning a maximum value of UINT16_MAX or 65k. Each variant contributes MAXALIGN(LVAR_HDRSIZE + len) bytes. With enough long variants, the value would wraparound. This would corrupt the data written by LQL_NEXT(), leading to a stack corruption, most likely translating into a crash, but it would allow incorrect memory access. - numvar, labelled as a uint16, counts the number of OR-variants in a single level, and it is incremented without bounds checking. With more than PG_UINT16_MAX (65k) variants in a single level, and a minimum of 131kB of input data, it would wrap to 0. When a (wildcard) '*' is used, this would change the query results silently.
For both issues, a set of overflows checks are added to guard against these problematic patterns. The first issue has been reported by the three people listed below, affecting v16 and newer versions due to b1665bf01e5f. Its coding was still unsafe in v14 and v15. The second issue affects all the stable branches; I have bumped into while reviewing the code of the module. Reported-by: Vergissmeinnicht <[email protected]> Reported-by: A1ex <[email protected]> Reported-by: Jihe Wang <[email protected]> Author: Michael Paquier <[email protected]> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/2f1b16e867e78cdd899fa7df3acb5f6e616a9371 Author: Michael Paquier <[email protected]> Modified Files -------------- contrib/ltree/expected/ltree.out | 10 ++++++++++ contrib/ltree/ltree_io.c | 19 +++++++++++++++++-- contrib/ltree/sql/ltree.sql | 8 ++++++++ 3 files changed, 35 insertions(+), 2 deletions(-)
