Thread: BUG #17474: Segmentation fault from INSERT ( JumbleExpr )

The following bug has been logged on the website:

Bug reference:      17474
Logged by:          Victor Yegorov
Email address:      vyegorov@gmail.com
PostgreSQL version: 14.2
Operating system:   Ubuntu 20.04.4 LTS (focal)
Description:

Quite simple setup, that works on 13 version, is causing SEGFAULTs on 14.2.
Reproducible.

*** Table definition ***

                                 Table "public.outputs"
     Column     |   Type    | Collation | Nullable |               Default
----------------+-----------+-----------+----------+-------------------------------------
 id             | integer   |           | not null |
nextval('outputs_id_seq'::regclass)
 transaction_id | integer   |           |          |
 address        | bigint    |           |          |
 position       | integer   |           |          |
 amount         | bigint    |           |          |
 type           | integer   |           |          |
 req_sigs       | integer   |           |          |
 multisig_type  | integer[] |           |          |
Indexes:
    "outputs_pkey" PRIMARY KEY, btree (id)
    "address" btree (address)
    "outputs_amount_idx" btree (amount)
    "transaction_id" btree (transaction_id)
    "trx_pos" btree (transaction_id, "position")
Foreign-key constraints:
    "outputs_transaction_id_fkey" FOREIGN KEY (transaction_id) REFERENCES
transactions(id) ON DELETE CASCADE
Referenced by:
    TABLE "inputs" CONSTRAINT "inputs_output_id_fkey" FOREIGN KEY
(output_id) REFERENCES outputs(id) ON DELETE CASCADE
    TABLE "output_datas" CONSTRAINT "output_datas_output_id_fkey" FOREIGN
KEY (output_id) REFERENCES outputs(id) ON DELETE CASCADE

*** INSERT statement ***

LOG:  server process (PID 2585336) was terminated by signal 11: Segmentation
fault
DETAIL:  Failed process was running: INSERT INTO outputs (transaction_id,
address, position, amount, type, req_sigs) VALUES (254800, 163252, 0, 1, 1,
1), (254800, 61860, 1, 1, 1, 1), (254800, 99617, 2, 1, 1, 1), (254800,
163255, 3, 1, 1, 1), (254800, 12098, 4, 1, 1, 1), (254800, 97997, 5, 1, 1,
1), (254800, 13404, 6, 1, 1, 1), (254800, 80413, 7, 1, 1, 1), (254800, 8319,
8, 1, 1, 1), (254800, 163261, 9, 1, 1, 1), (254800, 163262, 10, 1, 1, 1),
(254800, 163263, 11, 1, 1, 1), (254800, 163264, 12, 1, 1, 1), (254800,
163265, 13, 1, 1, 1), (254800, 163266, 14, 1, 1, 1), (254800, 163267, 15, 1,
1, 1), (254800, 163197, 16, 1, 1, 1), (254800, 163269, 17, 1, 1, 1),
(254800, 163270, 18, 1, 1, 1), (254800, 1238, 19, 1, 1, 1), (254800, 12093,
20, 1, 1, 1), (254800, 24167, 21, 1, 1, 1), (254800, 39000, 22, 1, 1, 1),
(254800, 163255, 23, 1, 1, 1), (254800, 163275, 24, 1, 1, 1), (254800,
93813, 25, 1, 1, 1), (254800, 163277, 26, 1, 1, 1), (254800, 163278, 27, 1,
1, 1), (254800, 8285, 28, 1, 1, 1), (254800, 9111, 29, 1, 1, 1), (254800,
54795, 30, 1, 1, 1), (254

Total length of the INSERT statement is round 100Kb.

*** Backtrace ***

Core was generated by `postgres: 14/main: parser litecoin 10.1.1.20(43434)
PARSE                     '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>,
__dest=<optimized out>) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
34      /usr/include/x86_64-linux-gnu/bits/string_fortified.h: No such file
or directory.
(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
#2  0x000056397d94c6c4 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized
out>) at ./build/../src/backend/utils/misc/queryjumble.c:373
#3  0x000056397d94c8c1 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized
out>) at ./build/../src/backend/utils/misc/queryjumble.c:743
#4  0x000056397d94c8c1 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized
out>) at ./build/../src/backend/utils/misc/queryjumble.c:743
#5  0x000056397d94c5dc in JumbleRangeTable (rtable=0x7f403966a020,
jstate=0x7f4038f652e0) at
./build/../src/backend/utils/misc/queryjumble.c:300
#6  JumbleQueryInternal (jstate=0x7f4038f652e0, query=0x7f4039669b28) at
./build/../src/backend/utils/misc/queryjumble.c:248
#7  0x000056397d94cfec in JumbleQuery (query=query@entry=0x7f4039669b28,
querytext=querytext@entry=0x56397fdb9b59 "") at
./build/../src/backend/utils/misc/queryjumble.c:127
#8  0x000056397d5e26b3 in parse_analyze_varparams
(parseTree=parseTree@entry=0x7f4039669aa8,
sourceText=sourceText@entry=0x56397fdb9b59 "",
paramTypes=paramTypes@entry=0x7fff3a4f6748,
numParams=numParams@entry=0x7fff3a4f6734)
    at ./build/../src/backend/parser/analyze.c:169
#9  0x000056397d80cc1e in exec_parse_message (numParams=<optimized out>,
paramTypes=<optimized out>, stmt_name=0x56397fdb9b58 "",
query_string=0x56397fdb9b59 "") at
./build/../src/backend/tcop/postgres.c:1458
#10 PostgresMain (argc=argc@entry=1, argv=argv@entry=0x7fff3a4f6a20,
dbname=<optimized out>, username=<optimized out>) at
./build/../src/backend/tcop/postgres.c:4515
#11 0x000056397d78cb6b in BackendRun (port=<optimized out>, port=<optimized
out>) at ./build/../src/backend/postmaster/postmaster.c:4530
#12 BackendStartup (port=<optimized out>) at
./build/../src/backend/postmaster/postmaster.c:4252
#13 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1745
#14 0x000056397d78d9ec in PostmasterMain (argc=<optimized out>,
argv=0x56397fbacf10) at
./build/../src/backend/postmaster/postmaster.c:1417
#15 0x000056397d506c8d in main (argc=5, argv=0x56397fbacf10) at
./build/../src/backend/main/main.c:209

PG Bug reporting form <noreply@postgresql.org> writes:
> Quite simple setup, that works on 13 version, is causing SEGFAULTs on 14.2.
> Reproducible.

Can you provide a reproducer SQL script?  The stack trace looks like
some element of the VALUES list is not in the format that JumbleExpr
is expecting, but there's nothing odd-looking about the fragment
you showed.

            regards, tom lane

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