mirror of
https://github.com/postgres/postgres.git
synced 2026-07-16 23:05:04 -04:00
9c2fa5b6ab
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
|
||
|---|---|---|
| .. | ||
| data | ||
| expected | ||
| sql | ||
| .gitignore | ||
| _ltree_gist.c | ||
| _ltree_op.c | ||
| crc32.c | ||
| crc32.h | ||
| lquery_op.c | ||
| ltree--1.0--1.1.sql | ||
| ltree--1.1--1.2.sql | ||
| ltree--1.1.sql | ||
| ltree.control | ||
| ltree.h | ||
| ltree_gist.c | ||
| ltree_io.c | ||
| ltree_op.c | ||
| ltreetest.sql | ||
| ltxtquery_io.c | ||
| ltxtquery_op.c | ||
| Makefile | ||