Re: Question concerning backport of CVE-2022-2625 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Question concerning backport of CVE-2022-2625
Date
Msg-id 2828861.1668962621@sss.pgh.pa.us
Whole thread Raw
In response to Question concerning backport of CVE-2022-2625  (Roberto C. Sánchez <roberto@debian.org>)
Responses Re: Question concerning backport of CVE-2022-2625
Re: Question concerning backport of CVE-2022-2625
List pgsql-hackers
Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= <roberto@debian.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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Slow standby snapshot
Next
From: Nathan Bossart
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE