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 ) id 1no7Ob-0005Dn-OC for pgsql-bugs@arkaria.postgresql.org; Mon, 09 May 2022 17:42:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1no7Oa-0004dI-IY for pgsql-bugs@arkaria.postgresql.org; Mon, 09 May 2022 17:42:08 +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 ) id 1no7Oa-0004cy-8M for pgsql-bugs@lists.postgresql.org; Mon, 09 May 2022 17:42:08 +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 ) id 1no7OX-0002ZZ-Oo; Mon, 09 May 2022 17:42:07 +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 249Hg29N3824038; Mon, 9 May 2022 13:42:02 -0400 From: Tom Lane To: "Jonathan S. Katz" cc: Masahiko Sawada , krking@zju.edu.cn, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17477: A crash bug in transformValuesClause() In-reply-to: <6f7f0d34-0f58-41a9-98b5-bf86e1960165@postgresql.org> References: <17477-0af3c6ac6b0a6ae0@postgresql.org> <3809468.1652109938@sss.pgh.pa.us> <6f7f0d34-0f58-41a9-98b5-bf86e1960165@postgresql.org> Comments: In-reply-to "Jonathan S. Katz" message dated "Mon, 09 May 2022 13:20:23 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3824036.1652118122.1@sss.pgh.pa.us> Date: Mon, 09 May 2022 13:42:02 -0400 Message-ID: <3824037.1652118122@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Jonathan S. Katz" writes: > Confirmed reproducing the crash and that this fixes it. I did a short > double-take on the error message: > ERROR: subquery must return only one column > but it is accurate, given this is what the subquery must do, and zero != > one. Yeah, that's just an artifact of the strange test case. A more straightforward usage might look like create table nocols(); select * from nocols n, lateral (values(n.*)) v; Anyway, this is not a security issue per our normal standards. It is a crash due to SIGSEGV, but I don't see any likelihood that it could be exploited for memory disclosure or arbitrary code execution, so the effects are limited to momentary denial of service. There are lots of ways to produce DOS if you have the ability to issue arbitrary SQL, so we generally don't consider that a security issue unless there's the possibility of doing more than just crashing one session. Having said that, a crash is unpleasant, so I'm going to take the small risk of pushing this not-very-well-vetted patch into today's releases. BTW, if this *had* been a security issue, we'd much rather you'd have reported it to security@postgresql.org. The bugs list is an open channel. regards, tom lane