Re: Question concerning backport of CVE-2022-2625

From: Roberto C(dot) Sánchez <roberto(at)debian(dot)org>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Question concerning backport of CVE-2022-2625
Date: 2022-11-20 22:00:45
Message-ID: Y3qjjcqjDr/C6p4H@connexer.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.
>
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-11-20 22:26:11 Re: perform_spin_delay() vs wait events
Previous Message Thomas Munro 2022-11-20 21:53:52 Re: More efficient build farm animal wakeup?