Re: Re[2]: CVE-2022-2625 - Mailing list pgsql-general

From Tom Lane
Subject Re: Re[2]: CVE-2022-2625
Date
Msg-id 3316951.1663255145@sss.pgh.pa.us
Whole thread Raw
In response to Re[2]: CVE-2022-2625  (misha1966 misha1966 <mmisha1966@bk.ru>)
Responses Re: CVE-2022-2625
Re: Re[2]: CVE-2022-2625
Re[4]: CVE-2022-2625
List pgsql-general
=?UTF-8?B?bWlzaGExOTY2IG1pc2hhMTk2Ng==?= <mmisha1966@bk.ru> writes:
> Is there a patch for 9.6 ?

No; that's out of support too.

You might find that adapting the v10 patch back to 9.6, and
thence to 9.5, would be easier than trying to do it in one step.

I'm a little bemused by your fixation on this particular CVE,
though.  As such things go, it's not a very big deal.  It's only
of interest if you are routinely installing new extensions, *and*
those extensions' scripts contain insecure uses of CREATE OR
REPLACE/CREATE IF NOT EXISTS, *and* you can't fix the extensions
instead.  I would not have thought an institution that's so
frozen that it can't update to an in-support PG version would be
doing a lot of new extension installations.

In any case, the real thing you ought to be focusing on is whether
you are running back-ported patches for any of the *other* CVE-worthy
security bugs we've fixed since 9.5 went EOL.  And how about the
data-corrupting bugs?  Most longtime PG developers think data
corruption hazards are a good deal more important than a lot of
the stuff we assign CVEs to.  Almost every CVE we've ever issued is
only relevant if you have hostile actors able to issue arbitrary SQL
in your database, in which case you're in a world of trouble anyway.

            regards, tom lane



pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: CVE-2022-2625
Next
From: Ron
Date:
Subject: Re: CVE-2022-2625