Re: Question concerning backport of CVE-2022-2625

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Roberto C(dot) Sánchez <roberto(at)debian(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Question concerning backport of CVE-2022-2625
Date: 2022-11-20 16:43:41
Message-ID: 2828861.1668962621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= <roberto(at)debian(dot)org> writes:
> -- this makes a shell "point <<@@ polygon" operator too
> CREATE OPERATOR @@>> ( PROCEDURE = poly_contain_pt,
> LEFTARG = polygon, RIGHTARG = point,
> COMMUTATOR = <<@@ );
> CREATE EXTENSION test_ext_cor; -- fail
> ERROR: operator <<@@(point,polygon) is not a member of extension "test_ext_cor"
> DETAIL: An extension is not allowed to replace an object that it does not own.
> DROP OPERATOR <<@@ (point, polygon);
> CREATE EXTENSION test_ext_cor; -- now it should work
> +ERROR: operator 16427 is not a member of extension "test_ext_cor"
> +DETAIL: An extension is not allowed to replace an object that it does not own.

That is ... odd. Since 9.4 is long out of support I'm unenthused
about investigating it myself. (Why is it that people will move heaven
and earth to fix "security" bugs in dead branches, but ignore even
catastrophic data-loss bugs?) But if you're stuck with pursuing
this exercise, I think you'd better figure out exactly what's
happening. I agree that it smells like c94959d41 could be related,
but I don't see just how that'd produce this symptom. Before that
commit, the DROP OPERATOR <<@@ would have left a dangling link
behind in @@>> 's oprcom field, but there doesn't seem to be a
reason why that'd affect the test_ext_cor extension: it will not
be re-using the same operator OID, nor would it have any reason to
touch @@>>, since there's no COMMUTATOR clause in the extension.

It'd likely be a good idea to reproduce this with a gdb breakpoint
set at errfinish, and see exactly what's leading up to the error.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-11-20 16:57:13 Re: predefined role(s) for VACUUM and ANALYZE
Previous Message Simon Riggs 2022-11-20 16:41:52 Re: Slow standby snapshot