MIME-Version: 1.0
References: <19545-0f25b7e47351e8fc@postgresql.org>
 <CAON2xHMXYLwkq4UaNbUtmaw1ZKne6OqdyyiACFQUbCj+XRBvQQ@mail.gmail.com>
 <d02fd089-b326-417a-ab2c-aea88e459c63@iki.fi>
 <CAON2xHPV-7O0MsFuizJv8cbUG7ZJfLCAqzkGYgoxF9WBe1v9Jg@mail.gmail.com>
 <d6680315-bc66-48c3-a310-bdad88a86a59@iki.fi>
In-Reply-To: <d6680315-bc66-48c3-a310-bdad88a86a59@iki.fi>
From: Ewan Young <kdbase.hack@gmail.com>
Date: Thu, 9 Jul 2026 13:16:54 +0800
Message-ID: 
 <CAON2xHN5qGXcn1Z00pQAogf4y5rCQ1K04yvrYAORBa5i+ucLBQ@mail.gmail.com>
Subject: Re: BUG #19545: Integer truncation of `GinTuple.keylen` causes
 out-of-bounds read in parallel GIN index build
To: Heikki Linnakangas <hlinnaka@iki.fi>,
 Peter Eisentraut <peter@eisentraut.org>
Cc: 1217816127@qq.com, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/mixed; boundary="0000000000004ce5f4065626bc38"
Archived-At: 
 <https://www.postgresql.org/message-id/CAON2xHN5qGXcn1Z00pQAogf4y5rCQ1K04yvrYAORBa5i%2BucLBQ%40mail.gmail.com>
Precedence: bulk

--0000000000004ce5f4065626bc38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Heikki and Peter,

On Wed, Jul 8, 2026 at 10:36=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki.fi=
> wrote:
>
> On 08/07/2026 14:34, Ewan Young wrote:
> > On Wed, Jul 8, 2026 at 3:52=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki=
.fi> wrote:
> >>
> >> On 08/07/2026 09:27, Ewan Young wrote:
> >>> Hi Yuelin,
> >>>
> >>> Thanks for the very precise report -- I reproduced it on master and y=
our
> >>> analysis is exactly right. _gin_build_tuple() builds the whole GinTup=
le
> >>> (palloc size, key memcpy, TID-list offset) from the int keylen, but t=
he
> >>> stored GinTuple.keylen is uint16, so a key wider than 65535 bytes has=
 its
> >>> stored length truncated. On read-back GinTupleGetFirst() and
> >>> _gin_parse_tuple_items() recompute the posting-list offset from the
> >>> truncated value, and ginPostingListDecodeAllSegments() then walks the=
 key
> >>> bytes, aborting (or reading past the allocation on non-assert builds)
> >>> exactly as you saw. It's parallel-only because only the parallel path
> >>> serializes a GinTuple.
> >>>
> >>> I went with your fix A -- widening keylen to uint32 (attached). It's =
the
> >>> minimal root-cause fix: the stored length now matches the length the =
rest
> >>> of the function already uses.
> >>
> >> Ugh, the datatypes used for keylen are all over the place. In GinTuple
> >> struct it was 'uint16', in GinBuffer it's Size, and in the
> >> _gin_build_tuple() function's local variable it's 'int'. Would be good
> >> to make them consistent.
> >
> > Good point, agreed. v2 (attached) uses int for keylen everywhere: in
> > GinTuple (was uint16) and in GinBuffer (was Size); the local in
> > _gin_build_tuple() was already int. int matches the tuplen and nitems
> > fields of GinTuple and is plenty wide (a key can't exceed the 1GB varle=
na
> > limit), so it seemed like the natural choice.
>
> When I built this with "-fsanitize=3Dalignment,undefined" flag, it
> triggers a sanity check in the 'jsonb' test:
>
> (gdb) bt
> #0  __pthread_kill_implementation (threadid=3D281473024218464,
> signo=3Dsigno@entry=3D6, no_tid=3Dno_tid@entry=3D0) at ./nptl/pthread_kil=
l.c:44
> #1  0x0000ffff89fa7e24 [PAC] in __pthread_kill_internal
> (threadid=3D<optimized out>, signo=3D6) at ./nptl/pthread_kill.c:89
> #2  0x0000ffff89f56940 in __GI_raise (sig=3Dsig@entry=3D6) at
> ../sysdeps/posix/raise.c:26
> #3  0x0000ffff89f41a84 [PAC] in __GI_abort () at ./stdlib/abort.c:77
> #4  0x0000ffff8a0fc600 [PAC] in __sanitizer::Abort () at
> ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp=
:143
> #5  0x0000ffff8a10bc94 [PAC] in __sanitizer::Die () at
> ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:5=
8
> #6  0x0000ffff8a0e7da0 [PAC] in __ubsan::ScopedReport::~ScopedReport
> (this=3Dthis@entry=3D0xffffd8a433d0, __in_chrg=3D<optimized out>)
>      at ../../../../src/libsanitizer/ubsan/ubsan_diag.cpp:402
> #7  0x0000ffff8a0eb10c [PAC] in handleTypeMismatchImpl (Data=3D<optimized
> out>, Pointer=3D187650525702668, Opts=3D...)
>      at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:137
> #8  0x0000ffff8a0ebc0c [PAC] in
> __ubsan::__ubsan_handle_type_mismatch_v1_abort (Data=3D<optimized out>,
> Pointer=3D<optimized out>)
>      at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:147
> #9  0x0000aaaab7d3f2e4 [PAC] in GinBufferKeyEquals
> (buffer=3D0xaaaacaee4330, tup=3D0xaaaacaed29f8) at
> ../src/backend/access/gin/gininsert.c:1382
> #10 0x0000aaaab7d414c0 in GinBufferCanAddKey (buffer=3D0xaaaacaee4330,
> tup=3D0xaaaacaed29f8) at ../src/backend/access/gin/gininsert.c:1633
> #11 0x0000aaaab7d42500 in _gin_process_worker_data
> (state=3D0xffffd8a43890, worker_sort=3D0xaaaacae16fb0, progress=3Dtrue) a=
t
> ../src/backend/access/gin/gininsert.c:1899
> #12 0x0000aaaab7d43618 in _gin_parallel_scan_and_build
> (state=3D0xffffd8a43890, ginshared=3D0xffff8b9b83a0,
> sharedsort=3D0xffff8b9b8340, heap=3D0xffff7d7012a8,
>      index=3D0xffff7d708768, sortmem=3D21845, progress=3Dtrue) at
> ../src/backend/access/gin/gininsert.c:2085
> #13 0x0000aaaab7d42378 in _gin_leader_participate_as_worker
> (buildstate=3D0xffffd8a43890, heap=3D0xffff7d7012a8, index=3D0xffff7d7087=
68)
>      at ../src/backend/access/gin/gininsert.c:1834
> #14 0x0000aaaab7d3d7b0 in _gin_begin_parallel
> (buildstate=3D0xffffd8a43890, heap=3D0xffff7d7012a8, index=3D0xffff7d7087=
68,
> isconcurrent=3Dtrue, request=3D2)
>      at ../src/backend/access/gin/gininsert.c:1103
> #15 0x0000aaaab7d3ae3c in ginbuild (heap=3D0xffff7d7012a8,
> index=3D0xffff7d708768, indexInfo=3D0xaaaacad8f5b0) at
> ../src/backend/access/gin/gininsert.c:700
> #16 0x0000aaaab807c110 in index_build (heapRelation=3D0xffff7d7012a8,
> indexRelation=3D0xffff7d708768, indexInfo=3D0xaaaacad8f5b0, isreindex=3Df=
alse,
> parallel=3Dtrue, progress=3Dtrue)
>      at ../src/backend/catalog/index.c:3099
> #17 0x0000aaaab8074514 in index_concurrently_build
> (heapRelationId=3D41578, indexRelationId=3D41993) at
> ../src/backend/catalog/index.c:1543
>
> That's this line:
>
> #9  0x0000aaaab7d3f2e4 [PAC] in GinBufferKeyEquals
> (buffer=3D0xaaaacaee4330, tup=3D0xaaaacaed29f8) at
> ../src/backend/access/gin/gininsert.c:1382
> 1382            tupkey =3D (buffer->typbyval) ? *(Datum *) tup->data :
> PointerGetDatum(tup->data);
>
> So we have a hidden assumption that 'data' is Datum-aligned.
>
>
> In _gin_parse_tuple_key() we do this instead:
>
>      Datum              key;
>      ...
>      if (a->typbyval)
>      {
>          memcpy(&key, a->data, a->keylen);
>          return key;
>      }
>
> That one doesn't require the alignment. I would be inclined to always
> use memcpy() when 'typbyval=3D=3Dtrue', as above, to not be sensitive to =
the
> alignment. However, I think we assume that it's aligned for the
> 'typbyval=3D=3Dfalse' case anyway, as we just do DatumGetPoint(a->data).

Good catch, and this is really surfaced by widening keylen: on master
GinTuple.data lands at offset 16, which is MAXALIGN'd, so that read is
(accidentally) fine; growing the header pushed data off an 8-byte
boundary and exposed the unaligned Datum load.

Rather than pad data back to MAXALIGN (which grows every GinTuple), I did
what you suggest here -- read the key via the existing
_gin_parse_tuple_key() helper, which already copies byval keys out with
memcpy() and so makes no alignment assumption. That also removes the
duplicated "byval ? deref : pointer" logic, so the key is now read the
same way everywhere; the byref branch is unchanged.

With the _gin_parse_tuple_key() change the sanitizer is clean -- both at th=
at
4-aligned offset and with Size (where data happens to be back to
MAXALIGN'd), so the fix doesn't depend on the realignment.

>
> The straightforward fix is to add padding to make 'data' MAXALIGNed. It
> makes GinTuples larger, which is bad for performance, but it's probably
> fine.
>
> That said, I actually wonder why we need to store 'typbyval' and
> 'typlen' in GinTuple at all. That information could be looked up using
> 'attrnum'. Maybe 'typbyval' is good for performance in the comparison
> functions, but AFAICS GinTuple->typbyval is only used to copy it into
> GinBuffer in GinBufferStoreTuple(), which I think could easily afford to
> look it up.

I like the idea, but they're not only used to seed GinBuffer -- typbyval
is also read on the sort's hot path, in _gin_parse_tuple_key() (and thus
_gin_compare_tuples()), which only receives the GinTuple, not the index
tupdesc. So dropping them means threading the attr metadata into the
tuplesort comparator, which felt like a larger, separable cleanup than
this fix. Happy to look at it as a follow-up if you think it's
worthwhile, but I'd lean toward not blocking the bug fix on it.

>
> >>> I preferred it over an explicit ereport at
> >>> UINT16_MAX, since 65535 isn't a meaningful GIN limit -- the entry-tre=
e item
> >>> limit is much smaller and is applied to the (compressed) tuple by
> >>> GinFormTuple() -- so rejecting there would be an arbitrary cutoff.
> >>
> >> Hmm, we don't compress the key data though, so a tuple with a key larg=
er
> >> than 65535 will inevitably fail in GinFormTuple(), right? I agree it
> >
> > That was my first thought too, but it turns out we do compress it, just
> > not in _gin_build_tuple(). GinFormTuple() builds the on-page tuple via
> > index_form_tuple(), whose TOAST_INDEX_HACK path compresses a compressib=
le
> > key over TOAST_INDEX_TARGET (~BLCKSZ/16) inline before the GinMaxItemSi=
ze
> > check runs. So that check sees the *compressed* key, and a large but
> > compressible key sails through. It's only the parallel path's GinTuple
> > that keeps the key uncompressed, which is exactly where the uint16
> > truncation bit us.
> >
> > Concretely, unpatched master indexes a key far larger than GinMaxItemSi=
ze
> > just fine in a serial build:
> >
> >      CREATE TABLE t (a text[]);
> >      INSERT INTO t SELECT ARRAY[repeat('x',100000)] FROM generate_serie=
s(1,50);
> >      SET max_parallel_maintenance_workers =3D 0;   -- force a serial bu=
ild
> >      CREATE INDEX ON t USING gin (a);             -- succeeds; key is
> > 100000 bytes
>
> Oh, ok, I stand corrected. Let's keep that working then.

Thanks -- leaving GinFormTuple() as the single size gate, then.

> Size (or size_t) is the correct type for sizes of objects in memory.
>
> Note that the return type of VARSIZE_ANY() is already Size, so by using
> int you are still doing a type truncation, and by using a signed type
> you are introducing unnecessary potential for confusion.

Agreed, that's clearly better. v3 (attached) uses Size for
GinTuple.keylen (GinBuffer.keylen already was Size), and also for the
local in _gin_build_tuple(), which was the int that truncated
VARSIZE_ANY() in the first place.

Thanks again for the review!

>
> - Heikki
>

--=20
Regards,
Ewan Young

--0000000000004ce5f4065626bc38
Content-Type: application/octet-stream;
	name="v3-0001-Fix-parallel-GIN-index-build-with-keys-larger-tha.patch"
Content-Disposition: attachment;
	filename="v3-0001-Fix-parallel-GIN-index-build-with-keys-larger-tha.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mrd1tabr0>
X-Attachment-Id: f_mrd1tabr0

RnJvbSAyZTJkNWM1Y2VjMmNlZmQwNGFlNjQ0ODZhODMzM2U0ZWQ0MTkxMTEyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBFd2FuIFlvdW5nIDxrZGJhc2UuaGFja0BnbWFpbC5jb20+CkRh
dGU6IFRodSwgOSBKdWwgMjAyNiAxODoxOTo1MSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggdjNdIEZp
eCBwYXJhbGxlbCBHSU4gaW5kZXggYnVpbGQgd2l0aCBrZXlzIGxhcmdlciB0aGFuIDY1NTM1CiBi
eXRlcwoKRHVyaW5nIGEgcGFyYWxsZWwgR0lOIGJ1aWxkIGVhY2gga2V5IGlzIHNlcmlhbGl6ZWQg
aW50byBhIEdpblR1cGxlLCBhCnRyYW5zaWVudCByZXByZXNlbnRhdGlvbiB1c2VkIG9ubHkgd2hp
bGUgc29ydGluZy4gIF9naW5fYnVpbGRfdHVwbGUoKQpsYXlzIG91dCB0aGUgd2hvbGUgdHVwbGUg
LS0gdGhlIHBhbGxvYyBzaXplLCB0aGUga2V5IG1lbWNweSwgYW5kIHRoZQpvZmZzZXQgdG8gdGhl
IHBvc3RpbmcgbGlzdCAtLSBmcm9tIGEgbG9jYWwga2V5bGVuIGhvbGRpbmcgVkFSU0laRV9BTlko
KQpvZiB0aGUga2V5LiAgQnV0IHRoZSBzdG9yZWQgR2luVHVwbGUua2V5bGVuIGZpZWxkIHdhcyB1
aW50MTYsIHNvIGEga2V5CndpZGVyIHRoYW4gNjU1MzUgYnl0ZXMgaGFkIGl0cyBzdG9yZWQgbGVu
Z3RoIHNpbGVudGx5IHRydW5jYXRlZC4KCk9uIHJlYWQtYmFjaywgR2luVHVwbGVHZXRGaXJzdCgp
IGFuZCBfZ2luX3BhcnNlX3R1cGxlX2l0ZW1zKCkgcmVjb21wdXRlCnRoZSBwb3N0aW5nLWxpc3Qg
b2Zmc2V0IGZyb20gdGhlIHRydW5jYXRlZCBrZXlsZW4gYW5kIGxhbmQgaW5zaWRlIHRoZQprZXkg
ZGF0YS4gIGdpblBvc3RpbmdMaXN0RGVjb2RlQWxsU2VnbWVudHMoKSB0aGVuIGRlY29kZXMgZ2Fy
YmFnZSwKdHJpcHBpbmcgYW4gYXNzZXJ0aW9uIChvciByZWFkaW5nIHBhc3QgdGhlIGFsbG9jYXRp
b24gaW4gYSBub24tYXNzZXJ0CmJ1aWxkKS4gIE9ubHkgcGFyYWxsZWwgYnVpbGRzIGFyZSBhZmZl
Y3RlZCwgYmVjYXVzZSBvbmx5IHRoZSBwYXJhbGxlbApwYXRoIG1hdGVyaWFsaXplcyBhIEdpblR1
cGxlLgoKV2lkZW4gR2luVHVwbGUua2V5bGVuIHRvIFNpemUgc28gdGhlIHN0b3JlZCBsZW5ndGgg
bWF0Y2hlcyB3aGF0Cl9naW5fYnVpbGRfdHVwbGUoKSBjb21wdXRlcy4gIFNpemUgaXMgdGhlIG5h
dHVyYWwgdHlwZSBoZXJlOiBpdCdzIHdoYXQKVkFSU0laRV9BTlkoKSByZXR1cm5zIGFuZCB3aGF0
IEdpbkJ1ZmZlci5rZXlsZW4gYWxyZWFkeSB1c2VzLiAgVGhlCl9naW5fYnVpbGRfdHVwbGUoKSBs
b2NhbCB3YXMgaW50LCB3aGljaCB0cnVuY2F0ZWQgVkFSU0laRV9BTlkoKSB0aGUKc2FtZSB3YXk7
IG1ha2UgaXQgU2l6ZSB0b28uCgpXaWRlbmluZyBrZXlsZW4gYWxzbyBtb3ZlcyBHaW5UdXBsZS5k
YXRhLCB3aGljaCBoYXBwZW5lZCB0byBsYW5kIGF0IGFuCjgtYnl0ZSBib3VuZGFyeSBiZWZvcmUu
ICBXaGlsZSB0aGUgU2l6ZSBsYXlvdXQga2VlcHMgZGF0YSBNQVhBTElHTmVkLApHaW5CdWZmZXJL
ZXlFcXVhbHMoKSBzaG91bGQgbm90IGRlcGVuZCBvbiB0aGF0OiBpdCByZWFkIGFuIHVuYWxpZ25l
ZApEYXR1bSB2aWEgIiooRGF0dW0gKikgdHVwLT5kYXRhIiBmb3IgYnl2YWwga2V5cy4gIFVzZQpf
Z2luX3BhcnNlX3R1cGxlX2tleSgpIHRoZXJlIGluc3RlYWQsIHdoaWNoIGNvcGllcyB0aGUga2V5
IG91dCB3aXRoCm1lbWNweSgpIGFuZCBzbyBtYWtlcyBubyBhc3N1bXB0aW9uIGFib3V0IHRoZSBh
bGlnbm1lbnQgb2YgdGhlIGRhdGEKYXJyYXksIG1hdGNoaW5nIGhvdyB0aGUga2V5IGlzIHJlYWQg
ZXZlcnl3aGVyZSBlbHNlLgoKQnVnOiAjMTk1NDUKUmVwb3J0ZWQtYnk6IFl1ZWxpbiBXYW5nIDwx
MjE3ODE2MTI3QHFxLmNvbT4KRGlzY3Vzc2lvbjogaHR0cHM6Ly9wb3N0Z3IuZXMvbS8xOTU0NS0w
ZjI1YjdlNDczNTFlOGZjQHBvc3RncmVzcWwub3JnCi0tLQogc3JjL2JhY2tlbmQvYWNjZXNzL2dp
bi9naW5pbnNlcnQuYyB8IDEwICsrKysrKy0tLS0KIHNyYy9pbmNsdWRlL2FjY2Vzcy9naW5fdHVw
bGUuaCAgICAgfCAgMiArLQogMiBmaWxlcyBjaGFuZ2VkLCA3IGluc2VydGlvbnMoKyksIDUgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvYWNjZXNzL2dpbi9naW5pbnNlcnQu
YyBiL3NyYy9iYWNrZW5kL2FjY2Vzcy9naW4vZ2luaW5zZXJ0LmMKaW5kZXggY2I5ZWQzYjU2M2Mu
LjUzZDJhM2Y5ZjcwIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9hY2Nlc3MvZ2luL2dpbmluc2Vy
dC5jCisrKyBiL3NyYy9iYWNrZW5kL2FjY2Vzcy9naW4vZ2luaW5zZXJ0LmMKQEAgLTEzNzYsMTAg
KzEzNzYsMTIgQEAgR2luQnVmZmVyS2V5RXF1YWxzKEdpbkJ1ZmZlciAqYnVmZmVyLCBHaW5UdXBs
ZSAqdHVwKQogCQlyZXR1cm4gdHJ1ZTsKIAogCS8qCi0JICogRm9yIHRoZSB0dXBsZSwgZ2V0IGVp
dGhlciB0aGUgZmlyc3Qgc2l6ZW9mKERhdHVtKSBieXRlcyBmb3IgYnl2YWwKLQkgKiB0eXBlcywg
b3IgYSBwb2ludGVyIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGRhdGEgYXJyYXkuCisJICogR2V0
IHRoZSBrZXkgZnJvbSB0aGUgdHVwbGUuIFdlIHVzZSBfZ2luX3BhcnNlX3R1cGxlX2tleSgpIHJh
dGhlciB0aGFuCisJICogcmVhZGluZyB0dXAtPmRhdGEgZGlyZWN0bHksIGJlY2F1c2UgZm9yIGJ5
dmFsIHR5cGVzIHRoZSBkYXRhIGlzIG9ubHkKKwkgKiBzdG9yZWQvcmVhZCB3aXRoIG1lbWNweSgp
ICh0aGUgZGF0YSBhcnJheSBpcyBub3QgZ3VhcmFudGVlZCB0byBiZQorCSAqIGFsaWduZWQgZW5v
dWdoIHRvIGRlcmVmZXJlbmNlIGFzIGEgRGF0dW0pLgogCSAqLwotCXR1cGtleSA9IChidWZmZXIt
PnR5cGJ5dmFsKSA/ICooRGF0dW0gKikgdHVwLT5kYXRhIDogUG9pbnRlckdldERhdHVtKHR1cC0+
ZGF0YSk7CisJdHVwa2V5ID0gX2dpbl9wYXJzZV90dXBsZV9rZXkodHVwKTsKIAogCXIgPSBBcHBs
eVNvcnRDb21wYXJhdG9yKGJ1ZmZlci0+a2V5LCBmYWxzZSwKIAkJCQkJCQl0dXBrZXksIGZhbHNl
LApAQCAtMjI0OCw3ICsyMjUwLDcgQEAgX2dpbl9idWlsZF90dXBsZShPZmZzZXROdW1iZXIgYXR0
cm51bSwgdW5zaWduZWQgY2hhciBjYXRlZ29yeSwKIAljaGFyCSAgICpwdHI7CiAKIAlTaXplCQl0
dXBsZW47Ci0JaW50CQkJa2V5bGVuOworCVNpemUJCWtleWxlbjsKIAogCWRsaXN0X211dGFibGVf
aXRlciBpdGVyOwogCWRsaXN0X2hlYWQJc2VnbWVudHM7CmRpZmYgLS1naXQgYS9zcmMvaW5jbHVk
ZS9hY2Nlc3MvZ2luX3R1cGxlLmggYi9zcmMvaW5jbHVkZS9hY2Nlc3MvZ2luX3R1cGxlLmgKaW5k
ZXggN2JkZTA1ZTJkZTQuLjk5YTMxNTc4YWMxIDEwMDY0NAotLS0gYS9zcmMvaW5jbHVkZS9hY2Nl
c3MvZ2luX3R1cGxlLmgKKysrIGIvc3JjL2luY2x1ZGUvYWNjZXNzL2dpbl90dXBsZS5oCkBAIC0y
Myw3ICsyMyw3IEBAIHR5cGVkZWYgc3RydWN0IEdpblR1cGxlCiB7CiAJaW50CQkJdHVwbGVuOwkJ
CS8qIGxlbmd0aCBvZiB0aGUgd2hvbGUgdHVwbGUgKi8KIAlPZmZzZXROdW1iZXIgYXR0cm51bTsJ
CS8qIGF0dG51bSBvZiBpbmRleCBrZXkgKi8KLQl1aW50MTYJCWtleWxlbjsJCQkvKiBieXRlcyBp
biBkYXRhIGZvciBrZXkgdmFsdWUgKi8KKwlTaXplCQlrZXlsZW47CQkJLyogYnl0ZXMgaW4gZGF0
YSBmb3Iga2V5IHZhbHVlICovCiAJaW50MTYJCXR5cGxlbjsJCQkvKiB0eXBsZW4gZm9yIGtleSAq
LwogCWJvb2wJCXR5cGJ5dmFsOwkJLyogdHlwYnl2YWwgZm9yIGtleSAqLwogCXNpZ25lZCBjaGFy
IGNhdGVnb3J5OwkJLyogY2F0ZWdvcnk6IG5vcm1hbCBvciBOVUxMPyAqLwotLSAKMi40Ny4zCgo=
--0000000000004ce5f4065626bc38--