pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: ltree: Fix overflows with lquery parsing 6+ messages / 1 participants [nested] [flat]
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/2f1b16e867e78cdd899fa7df3acb5f6e616a9371 Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7f019f34140ab9b98ba1ede6cb9f4ed90296b50f Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8c3426110934af82590eb212ad5a282a9c5f7070 Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6b6b26fdecc8a8e0b57ab9f0e8a6ad6212ccba36 Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9c2fa5b6ab6fbf717eb2d8fb85d8c8fb97e4e965 Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: ltree: Fix overflows with lquery parsing @ 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 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 <vergissmeinnichtzh@gmail.com> Reported-by: A1ex <alex000young@gmail.com> Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-6473 Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b545c3787671ccbc54e76198da57424636a34f80 Author: Michael Paquier <michael@paquier.xyz> 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(-) ^ 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: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: ltree: Fix overflows with lquery parsing Noah Misch <noah@leadboat.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox