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

From Roberto C. Sánchez
Subject Re: Question concerning backport of CVE-2022-2625
Date
Msg-id Y3qjjcqjDr/C6p4H@connexer.com
Whole thread Raw
In response to Re: Question concerning backport of CVE-2022-2625  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi Tom,

On Sun, Nov 20, 2022 at 11:43:41AM -0500, Tom Lane wrote:
> 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.
> 
I understand your reticence to dive into a branch that is long dead from
your perspective.  That said, I am grateful for the insights you
provided here.

> 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.
> 
Thanks for this suggestion.  I will see if I am able to isolate the
precise cause of the failure with this.

Regards,

-Roberto

-- 
Roberto C. Sánchez



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: More efficient build farm animal wakeup?
Next
From: Robert Haas
Date:
Subject: Re: perform_spin_delay() vs wait events