Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1nmd9m-0004rD-AQ
	for pgsql-bugs@arkaria.postgresql.org; Thu, 05 May 2022 15:12:42 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1nmd9l-0004TE-5A
	for pgsql-bugs@arkaria.postgresql.org; Thu, 05 May 2022 15:12:41 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1nmd9k-0004SZ-TR
	for pgsql-bugs@lists.postgresql.org; Thu, 05 May 2022 15:12:40 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1nmd9i-0007xn-5g
	for pgsql-bugs@lists.postgresql.org; Thu, 05 May 2022 15:12:39 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 245FCaKh2689774;
	Thu, 5 May 2022 11:12:36 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vyegorov@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17474: Segmentation fault from INSERT ( JumbleExpr )
In-reply-to: <17474-60868309e99b1fca@postgresql.org>
References: <17474-60868309e99b1fca@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 05 May 2022 12:10:19 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2689772.1651763556.1@sss.pgh.pa.us>
Date: Thu, 05 May 2022 11:12:36 -0400
Message-ID: <2689773.1651763556@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/2689773.1651763556%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> (gdb) bt
> #0  0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>,
> __dest=<optimized out>) at
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> #1  AppendJumble (item=<optimized out>, item@entry=0x7f403929afd8 "u",
> size=30595144541, size@entry=4, jstate=<optimized out>, jstate=<optimized
> out>) at ./build/../src/backend/utils/misc/queryjumble.c:213

If we take that at face value --- which isn't a very safe assumption when
dealing with optimized code --- it suggests that the loop in AppendJumble
has gone crazy and allowed "size" to wrap around to some large value.
If that happened then it'd iterate until "item" advances off the end of
memory and you get SIGSEGV.

I don't see how that could possibly happen though, short of a compiler
bug:

    while (size > 0)
    {
        Size        part_size;
        ...
        part_size = Min(size, JUMBLE_SIZE - jumble_len);
        ...
        size -= part_size;
    }

How could the value of part_size exceed size?

I've spent time staring at that code before, because Coverity regularly
whines about queryjumble.c in terms suggesting that it sees a potential
for exactly this kind of bug.  But I sure don't see it.

			regards, tom lane