Fw:Re: Fw: gbt_var_consistent in contrib/btree_gist/btree_utils_var.c has internal-node type confusion on the <> strategy, bypassing exclusion constraints

王跃林 <violin0613@tju.edu.cn>

From: 王跃林 <violin0613@tju.edu.cn>
To: pgsql-bugs <pgsql-bugs@postgresql.org>
Date: 2026-06-16T11:29:35Z
Lists: pgsql-bugs







 王跃林
3020001251@tju.edu.cn










Forwarded message:
From:Noah Misch <noah@leadboat.com>Date:2026-06-13 08:29:28(中国 (GMT+08:00))To:王跃林<violin0613@tju.edu.cn>Cc:security <security@postgresql.org>Subject:Re: Fw: gbt_var_consistent in contrib/btree_gist/btree_utils_var.c has internal-node type confusion on the <> strategy, bypassing exclusion constraintsOn Mon, Jun 08, 2026 at 11:24:02PM +0800, 王跃林 wrote:
> gbt_var_node_truncate (btree_utils_var.c:214) truncates internal node keys to a common-prefix length. The resulting bytea can have VARSIZE anywhere from 4 upward. When the truncated VARSIZE is below 8 and that key reaches bit_cmp via the buggy BtreeGistNotEqual branch, bytelen becomes negative. Passed to memcmp as size_t, that is several GB. ASan catches it as negative-size-param. A production build without ASan will eventually SEGV when the read crosses an unmapped page.

Got it.  That doesn't qualify as a vuln per
https://www.postgresql.org/support/security/:

  The PostgreSQL Security Team typically does not consider a denial-of-service
  on a PostgreSQL server from an authenticated, valid SQL statement to be a
  security vulnerability. A denial-of-service issue of this nature could still
  be a bug, and we encourage you to report it on the Report a Bug page.

If nobody objects by 2026-06-16T00:00+0000, please report the bug to
pgsql-bugs@postgresql.org.



Commits

  1. Remove btree_gist's useless logic for encoding-aware truncation.

  2. Tighten up btree_gist's handling of truncated bounds.

  3. Sync signatures of gbt_var_consistent() and gbt_num_consistent().

  4. Fix btree_gist's NotEqual strategy on internal index pages.

  5. Reverse-engineer some documentation for btree_gist's varlena modules.

  6. Use the proper comparator in gbt_bit_ssup_cmp.