Backend crash in expanded_record_info functions

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Backend crash in expanded_record_info functions
Date: 2026-11-10 02:06:37
Message-ID: CAHewXNnDBGifxSqHvt1Xg4XmTL4=kQauQRo2kyWP4Yhz0bPG9w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While testing the current master with SQLsmith, I found a query that crashes
the backend. After running the regression tests, the issue can be
reproduced in the regression database with:

postgres=# \c regression
You are now connected to database "regression" as user "ubuntu".
regression=# SELECT expanded_record_info(2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

(gdb) bt
#0 0x000062d8180991a3 in VARATT_IS_EXTERNAL (PTR=0x2) at
../../../../src/include/varatt.h:403
#1 0x000062d8180991c5 in VARATT_IS_EXTERNAL_EXPANDED_RW (PTR=0x2) at
../../../../src/include/varatt.h:436
#2 0x000062d81809a654 in DatumGetExpandedRecord (d=2) at expandedrecord.c:847
#3 0x000076332abce2b7 in expanded_record_info (fcinfo=0x62d845e6d230)
at regress.c:475
#4 0x000062d817cce8ba in ExecInterpExpr (state=0x62d845e6cca0,
econtext=0x62d845e6c480, isnull=0x7ffcbda7663f) at
execExprInterp.c:987
#5 0x000062d817cd1502 in ExecInterpExprStillValid
(state=0x62d845e6cca0, econtext=0x62d845e6c480, isNull=0x7ffcbda7663f)
at execExprInterp.c:2309
#6 0x000062d817d3bae2 in ExecEvalExprSwitchContext
(state=0x62d845e6cca0, econtext=0x62d845e6c480, isNull=0x7ffcbda7663f)
at ../../../src/include/executor/executor.h:452
#7 0x000062d817d3bc33 in ExecQual (state=0x62d845e6cca0,
econtext=0x62d845e6c480) at
../../../src/include/executor/executor.h:539
#8 0x000062d817d3c01b in ExecScanExtended (node=0x62d845e6c370,
accessMtd=0x62d817d3c08a <SeqNext>, recheckMtd=0x62d817d3c16f
<SeqRecheck>,

The function has a polymorphic argument, so a scalar value such as an
integer is accepted during function resolution. However,
expanded_record_info() passes the argument directly to
DatumGetExpandedRecord() through PG_GETARG_EXPANDED_RECORD(), assuming
that it is a composite Datum. The integer value 2 is consequently treated
as a pointer, causing an access at address 0x2 and crashing the backend.

The same issue exists in expanded_record_identity() and
expanded_record_field_text(), since they make the same assumption about
their polymorphic arguments.

The attached patch checks that the resolved argument type is a row
type before converting the Datum.

--
Thanks,
Tender Wang

Attachment Content-Type Size
0001-Validate-expanded-record-test-function-arguments.patch text/plain 2.6 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-11-10 02:51:13 Re: Fix cumulative WAL statistics double-counting from parallel workers
Previous Message Masahiko Sawada 2026-11-10 01:46:12 Re: Pass heap tuple counts to parallel vacuum as double