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

Greetings PGSQL hackers,

I am working on a backport of CVE-2022-2625 to PostgreSQL 9.6 and 9.4.
I am starting from commit 5919bb5a5989cda232ac3d1f8b9d90f337be2077.

The backport to 9.6 was relatively straightforward, the principal change
being to omit some of the hunks related to commands in 9.6 that did not
have support for 'IF NOT EXISTS'.  When it came to 9.4, things got a
little more interesting.  There were additional instances of commands
that did not have support for 'IF NOT EXISTS' and some of the
contructions were slightly different as well, but nothing insurmountable
there.

I did have to hack at the 9.4 test harness a bit since the
test_extensions sub-directory seems to have been introduced post-9.4 and
it seemed like a good idea to have the actual tests from the
aforementioned commit to help guard against some sort of unintended
change on my part.  However, after I got through the CINE changes and
started dealing with the COR changes I ran into something fairly
peculiar.  The test output included this:

 DROP VIEW ext_cor_view; 
 CREATE TYPE test_ext_type;
 CREATE EXTENSION test_ext_cor;  -- fail
 ERROR:  type test_ext_type 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 TYPE test_ext_type;
 -- 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.
 SELECT ext_cor_func();

This made me suspect that there was an issue with 'DROP OPERATOR'.
After a little scavenger hunt, I located a commit which appears to be
related, c94959d4110a1965472956cfd631082a96f64a84, and which was made
post-9.4.  So then, my question: is the existing behavior that produces
"ERROR:  operator ... is not a member of extension ..." a sufficient
guard against the CVE-2022-2625 vulnerability when it comes to
operators?  (My thought is that it might be sufficient, and if it is I
would need to add something like 'DROP OPERATOR @@>> (point, polygon);'
to allow the extension creation to work and the test to complete.)

If the apparently buggy behavior is not a sufficient guard, then is a
backport of c94959d4110a1965472956cfd631082a96f64a84 in conjunction with
the CVE-2022-2625 fix the correct solution?

Regards,

-Roberto

-- 
Roberto C. Sánchez