Thread: SELECT with COLLATE results in segfault on trunk and 12 Beta 2
Hi everyone, When executing the statements below, Postgres crashes: CREATE TABLE t0(c0 BOOLEAN, c1 TEXT); CREATE STATISTICS s1 ON c0, c1 FROM t0; INSERT INTO t0(c0) VALUES (FALSE); VACUUM ANALYZE t0; SELECT * FROM t0 WHERE t0.c0 OR '' >= t0.c1 COLLATE "C"; -- unexpected: segfault The server log on the latest trunk version (5925e55) shows the following: 2019-07-14 23:09:58.070 CEST [11236] LOG: server process (PID 11245) was terminated by signal 11: Segmentation fault 2019-07-14 23:09:58.070 CEST [11236] DETAIL: Failed process was running: SELECT * FROM t0 WHERE t0.c0 OR '' >= t0.c1 COLLATE "C"; 2019-07-14 23:09:58.070 CEST [11236] LOG: terminating any other active server processes I could reproduce the segfault on the latest trunk version (PostgreSQL 13devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0, 64-bit), beta version (12beta2 (Debian 12~beta2-1.pgdg90+1)), but not on the latest release version (11.4 (Debian 11.4-1.pgdg90+1)). Since the bug is not reproducible on the latest release version, I assume that this is not a security issue. Best, Manuel
Manuel Rigger <rigger.manuel@gmail.com> writes:
> When executing the statements below, Postgres crashes:
> CREATE TABLE t0(c0 BOOLEAN, c1 TEXT);
> CREATE STATISTICS s1 ON c0, c1 FROM t0;
> INSERT INTO t0(c0) VALUES (FALSE);
> VACUUM ANALYZE t0;
> SELECT * FROM t0 WHERE t0.c0 OR '' >= t0.c1 COLLATE "C"; -- unexpected: segfault
Backtrace shows
#0 pg_detoast_datum_packed (datum=0x7f7f7f7f7f7f7f7f) at fmgr.c:1773
#1 0x00000000008a9b90 in text_ge (fcinfo=0x7ffc8cdbfd40) at varlena.c:1859
#2 0x00000000008cf307 in FunctionCall2Coll (flinfo=0x7ffc8cdbfe00,
collation=<value optimized out>, arg1=<value optimized out>,
arg2=<value optimized out>) at fmgr.c:1162
#3 0x0000000000773db0 in mcv_get_match_bitmap (root=0x26b7bc8,
clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
is_or=true) at mcv.c:1661
#4 0x0000000000773ecb in mcv_get_match_bitmap (root=0x26b7bc8,
clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
is_or=false) at mcv.c:1744
#5 0x0000000000775d61 in mcv_clauselist_selectivity (root=0x26b7bc8,
stat=0x26b8b58, clauses=0x26b9008, varRelid=<value optimized out>,
jointype=<value optimized out>, sjinfo=<value optimized out>,
rel=0x25a46a0, basesel=0x7ffc8cdc0038, totalsel=0x7ffc8cdc0030)
at mcv.c:1876
I think this is another variant of the mcv_get_match_bitmap
issues that you and Andreas already reported, ie, that code isn't
expecting to find anything but a bare Var or Const, so the
CollateExpr node above the Var confuses it.
It's possible that it'd be worth descending through CollateExpr
nodes in the same way as for RelabelType nodes, and for more or
less the same reason.
regards, tom lane
Hi everyone,
the following statements also result in a segfault on the current
trunk (in toast_raw_datum_size()):
CREATE TABLE t0(c0 TEXT, c1 TEXT, PRIMARY KEY(c0, c1));
CREATE TABLE t1(c0 TEXT, c1 TEXT, FOREIGN KEY (c0, c1) REFERENCES t0(c0, c1));
CREATE STATISTICS s0 ON c0, c1 FROM t0;
INSERT INTO t0(c1, c0) VALUES('a', 'a'), ('b', 'a'), ('c', 'a'), ('d',
'a'), ('e', 'a'), ('f', 'a');
ANALYZE;
UPDATE t0 SET c0 = 'b';
This segfault seems to be related to the previous one that I reported,
since it also happens in texteq(), although in a different function:
#0 0x0000560ac2a82e90 in toast_raw_datum_size ()
#1 0x0000560ac2e264f8 in texteq ()
#2 0x0000560ac2e4e5ca in FunctionCall2Coll ()
#3 0x0000560ac2cf4e3c in mcv_get_match_bitmap ()
#4 0x0000560ac2cf71a1 in mcv_clauselist_selectivity ()
#5 0x0000560ac2cf36a4 in statext_clauselist_selectivity ()
#6 0x0000560ac2c523bb in clauselist_selectivity ()
#7 0x0000560ac2c583ed in set_baserel_size_estimates ()
#8 0x0000560ac2c4fb90 in set_rel_size ()
#9 0x0000560ac2c51580 in make_one_rel ()
For these statements, the data changed by the UPDATE is lost.
Would you consider this bug to be distinct, or is it the same as the
previous one that I reported?
I could not reproduce this on the latest release version, so I assume
again that this is not a security issue.
Best,
Manuel
On Mon, Jul 15, 2019 at 12:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Manuel Rigger <rigger.manuel@gmail.com> writes:
> > When executing the statements below, Postgres crashes:
>
> > CREATE TABLE t0(c0 BOOLEAN, c1 TEXT);
> > CREATE STATISTICS s1 ON c0, c1 FROM t0;
> > INSERT INTO t0(c0) VALUES (FALSE);
> > VACUUM ANALYZE t0;
> > SELECT * FROM t0 WHERE t0.c0 OR '' >= t0.c1 COLLATE "C"; -- unexpected: segfault
>
> Backtrace shows
>
> #0 pg_detoast_datum_packed (datum=0x7f7f7f7f7f7f7f7f) at fmgr.c:1773
> #1 0x00000000008a9b90 in text_ge (fcinfo=0x7ffc8cdbfd40) at varlena.c:1859
> #2 0x00000000008cf307 in FunctionCall2Coll (flinfo=0x7ffc8cdbfe00,
> collation=<value optimized out>, arg1=<value optimized out>,
> arg2=<value optimized out>) at fmgr.c:1162
> #3 0x0000000000773db0 in mcv_get_match_bitmap (root=0x26b7bc8,
> clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
> is_or=true) at mcv.c:1661
> #4 0x0000000000773ecb in mcv_get_match_bitmap (root=0x26b7bc8,
> clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
> is_or=false) at mcv.c:1744
> #5 0x0000000000775d61 in mcv_clauselist_selectivity (root=0x26b7bc8,
> stat=0x26b8b58, clauses=0x26b9008, varRelid=<value optimized out>,
> jointype=<value optimized out>, sjinfo=<value optimized out>,
> rel=0x25a46a0, basesel=0x7ffc8cdc0038, totalsel=0x7ffc8cdc0030)
> at mcv.c:1876
>
> I think this is another variant of the mcv_get_match_bitmap
> issues that you and Andreas already reported, ie, that code isn't
> expecting to find anything but a bare Var or Const, so the
> CollateExpr node above the Var confuses it.
>
> It's possible that it'd be worth descending through CollateExpr
> nodes in the same way as for RelabelType nodes, and for more or
> less the same reason.
>
> regards, tom lane
On Mon, Jul 15, 2019 at 01:14:27PM +0200, Manuel Rigger wrote: > Would you consider this bug to be distinct, or is it the same as the > previous one that I reported? I think that Tom has the right call here and that we have the same issue as reported on the other thread. I have quickly looked at the set of patches sent by Tomas here: https://www.postgresql.org/message-id/20190715013425.v2hqfq5ubcbslw67@development And these are fixing the issues reported on this thread. > I could not reproduce this on the latest release version, so I assume > again that this is not a security issue. Live bugs on non-released versions are not security issues. They may become so if they represent an actual security problem (say memory disclosure with a logged in user, etc.) after v12 is GA though. -- Michael
Attachment
Hi Michael, Thank you very much for the feedback and pointing me to the patches! I'm very much looking forward to them being integrated. :) Best, Manuel On Tue, Jul 16, 2019 at 8:01 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Jul 15, 2019 at 01:14:27PM +0200, Manuel Rigger wrote: > > Would you consider this bug to be distinct, or is it the same as the > > previous one that I reported? > > I think that Tom has the right call here and that we have the same > issue as reported on the other thread. I have quickly looked at the > set of patches sent by Tomas here: > https://www.postgresql.org/message-id/20190715013425.v2hqfq5ubcbslw67@development > > And these are fixing the issues reported on this thread. > > > I could not reproduce this on the latest release version, so I assume > > again that this is not a security issue. > > Live bugs on non-released versions are not security issues. They > may become so if they represent an actual security problem (say memory > disclosure with a logged in user, etc.) after v12 is GA though. > -- > Michael
Manuel Rigger <rigger.manuel@gmail.com> writes:
> Thank you very much for the feedback and pointing me to the patches!
> I'm very much looking forward to them being integrated. :)
I confirmed that neither of the examples in this thread fail on
today's HEAD or v12 branch tip. Thanks for reporting!
regards, tom lane