Initialize padding bytes in btree_gist varbit support.

The code expands a varbit gist leaf key to a node key by copying the bit
data twice in a varlen datum, as both the lower and upper key. The lower key
was expanded to INTALIGN size, but the padding bytes were not initialized.
That's a problem because when the lower/upper keys are compared, the padding
bytes are used compared too, when the values are otherwise equal. That could
lead to incorrect query results.

REINDEX is advised for any btree_gist indexes on bit or bit varying data
type, to fix any garbage padding bytes on disk.

Per Valgrind, reported by Andres Freund. Backpatch to all supported
versions.

diff --git a/contrib/btree_gist/btree_bit.c b/contrib/btree_gist/btree_bit.c
index edf75e068421cda7572bcacf5fc66a3e813e3889..76297515c5e23f626fa674523f84f0ff5f0e80e2 100644 (file)
--- a/contrib/btree_gist/btree_bit.c
+++ b/contrib/btree_gist/btree_bit.c
@@ -75,10 +75,14 @@ static bytea *
 gbt_bit_xfrm(bytea *leaf)
 {
        bytea      *out = leaf;
-       int                     s = INTALIGN(VARBITBYTES(leaf) + VARHDRSZ);
-
-       out = palloc(s);
-       SET_VARSIZE(out, s);
+       int                     sz = VARBITBYTES(leaf) + VARHDRSZ;
+       int                     padded_sz = INTALIGN(sz);
+
+       out = (bytea *) palloc(padded_sz);
+       /* initialize the padding bytes to zero */
+       while (sz < padded_sz)
+               ((char *) out)[sz++] = 0;
+       SET_VARSIZE(out, padded_sz);
        memcpy((void *) VARDATA(out), (void *) VARBITS(leaf), VARBITBYTES(leaf));
        return out;
 }