-
postgresql-13 (13.7-0ubuntu0.21.10.1) impish-security; urgency=medium
* New upstream version (LP: #1973627).
+ A dump/restore is not required for those running 13.X.
+ However, if you have any GiST indexes on columns of type ltree (supplied
by the contrib/ltree extension), you should re-index them after updating.
See the upstream changelog linked below for further information.
+ Also, if you are upgrading from a version earlier than 13.6, see
those release notes as well please.
+ Confine additional operations within "security restricted operation"
sandboxes (Sergey Shinderuk, Noah Misch).
Autovacuum, CLUSTER, CREATE INDEX, REINDEX, REFRESH MATERIALIZED VIEW,
and pg_amcheck activated the "security restricted operation" protection
mechanism too late, or even not at all in some code paths. A user having
permission to create non-temporary objects within a database could
define an object that would execute arbitrary SQL code with superuser
permissions the next time that autovacuum processed the object, or that
some superuser ran one of the affected commands against it.
The PostgreSQL Project thanks Alexander Lakhin for reporting this
problem.
(CVE-2022-1552)
+ Details about these and many further changes can be found at:
https://www.postgresql.org/docs/13/release-13-7.html
-- Athos Ribeiro <email address hidden> Tue, 17 May 2022 10:58:43 -0300
-
postgresql-13 (13.6-0ubuntu0.21.10.1) impish; urgency=medium
* New upstream version (LP: #1961127).
+ A dump/restore is not required for those running 13.X.
+ However, if you have applied REINDEX CONCURRENTLY to a TOAST table's
index, or observe failures to access TOAST datums, there has been a
fix for this problem. Any existing corrupted indexes can be repaired
by reindexing again.
+ Also, if you are upgrading from a version earlier than 13.5,
see those release notes as well please.
+ Details about these and many further changes can be found at:
https://www.postgresql.org/docs/13/release-13-6.html
-- Sergio Durigan Junior <email address hidden> Wed, 16 Feb 2022 21:17:27 -0500
-
postgresql-13 (13.5-0ubuntu0.21.10.1) impish-security; urgency=medium
* New upstream version (LP: #1950268).
+ Make the server reject extraneous data after an SSL or GSS
encryption handshake
CVE-2021-23214
+ Make libpq reject extraneous data after an SSL or GSS
encryption handshake
CVE-2021-23222
+ A dump/restore is not required for those running 13.X.
+ However, note that installations using physical replication should
update standby servers before the primary server, details in the
release notes linked below.
+ Also, several bugs have been found that may have resulted in corrupted
indexes, explained in detail in the release notes linked below. If any
of those cases apply to you, it's recommended to reindex
possibly-affected indexes after updating.
+ Also, if you are upgrading from a version earlier than 13.2,
see those release notes as well please.
+ Details about these and many further changes can be found at:
https://www.postgresql.org/docs/13/release-13-5.html
-- Christian Ehrhardt <email address hidden> Tue, 09 Nov 2021 09:46:55 +0100
-
postgresql-13 (13.4-1) unstable; urgency=medium
* New upstream version.
+ Fix mis-planning of repeated application of a projection step (Tom Lane)
The planner could create an incorrect plan in cases where two
ProjectionPaths were stacked on top of each other. The only known way
to trigger that situation involves parallel sort operations, but there
may be other instances. The result would be crashes or incorrect query
results. Disclosure of server memory contents is also possible.
(CVE-2021-3677)
+ Disallow SSL renegotiation more completely (Michael Paquier)
SSL renegotiation has been disabled for some time, but the server would
still cooperate with a client-initiated renegotiation request. A
maliciously crafted renegotiation request could result in a server crash
(see OpenSSL issue CVE-2021-3449). Disable the feature altogether on
OpenSSL versions that permit doing so, which are 1.1.0h and newer.
* Remove obsolete #dbg# and #PIE# code.
-- Christoph Berg <email address hidden> Tue, 18 May 2021 13:56:18 +0200
-
postgresql-13 (13.3-1build1) impish; urgency=medium
* No-change rebuild due to OpenLDAP soname bump.
-- Sergio Durigan Junior <email address hidden> Mon, 21 Jun 2021 18:07:46 -0400
-
postgresql-13 (13.3-1) unstable; urgency=medium
* New upstream version.
+ Prevent integer overflows in array subscripting calculations (Tom Lane)
The array code previously did not complain about cases where an array's
lower bound plus length overflows an integer. This resulted in later
entries in the array becoming inaccessible (since their subscripts could
not be written as integers), but more importantly it confused subsequent
assignment operations. This could lead to memory overwrites, with
ensuing crashes or unwanted data modifications. (CVE-2021-32027)
+ Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
target lists (Tom Lane)
If the UPDATE list contains any multi-column sub-selects (which give
rise to junk columns in addition to the results proper), the UPDATE path
would end up storing tuples that include the values of the extra junk
columns. That's fairly harmless in the short run, but if new columns are
added to the table then the values would become accessible, possibly
leading to malfunctions if they don't match the datatypes of the added
columns.
In addition, in versions supporting cross-partition updates, a
cross-partition update triggered by such a case had the reverse problem:
the junk columns were removed from the target list, typically causing an
immediate crash due to malfunction of the multi-column sub-select
mechanism. (CVE-2021-32028)
+ Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
joined cross-partition updates (Amit Langote, Etsuro Fujita)
If an UPDATE for a partitioned table caused a row to be moved to another
partition with a physically different row type (for example, one with a
different set of dropped columns), computation of RETURNING results for
that row could produce errors or wrong answers. No error is observed
unless the UPDATE involves other tables being joined to the target
table. (CVE-2021-32029)
* Mark libio-pty-perl and libipc-run-perl as <!nocheck>. (Closes: #988121)
-- Christoph Berg <email address hidden> Tue, 11 May 2021 22:10:35 +0200
-
postgresql-13 (13.2-1) unstable; urgency=medium
* New upstream version.
+ Fix failure to check per-column SELECT privileges in some join queries
(Tom Lane)
In some cases involving joins, the parser failed to record all the
columns read by a query in the column-usage bitmaps that are used for
permissions checking. Although the executor would still insist on some
sort of SELECT privilege to run the query, this meant that a user having
SELECT privilege on only one column of a table could nonetheless read
all its columns through a suitably crafted query.
A stored view that is subject to this problem will have incomplete
column-usage bitmaps, and thus permissions will still not be enforced
properly on the view after updating. In installations that depend on
column-level permissions for security, it is recommended to CREATE OR
REPLACE all user-defined views to cause them to be re-parsed.
The PostgreSQL Project thanks Sven Klemm for reporting this problem.
(CVE-2021-20229)
+ Fix information leakage in constraint-violation error messages
(Heikki Linnakangas)
If an UPDATE command attempts to move a row to a different partition but
finds that it violates some constraint on the new partition, and the
columns in that partition are in different physical positions than in
the parent table, the error message could reveal the contents of columns
that the user does not have SELECT privilege on. (CVE-2021-3393)
+ Fix incorrect detection of concurrent page splits while inserting into a
GiST index (Heikki Linnakangas)
Concurrent insertions could lead to a corrupt index with entries placed
in the wrong pages. It's recommended to reindex any GiST index that's
been subject to concurrent insertions.
+ Fix CREATE INDEX CONCURRENTLY to wait for concurrent prepared
transactions (Andrey Borodin)
At the point where CREATE INDEX CONCURRENTLY waits for all concurrent
transactions to complete so that it can see rows they inserted, it must
also wait for all prepared transactions to complete, for the same
reason. Its failure to do so meant that rows inserted by prepared
transactions might be omitted from the new index, causing queries
relying on the index to miss such rows. In installations that have
enabled prepared transactions (max_prepared_transactions > 0), it's
recommended to reindex any concurrently-built indexes in case this
problem occurred when they were built.
[ Christoph Berg ]
* Remove obsolete --enable-integer-datetimes configure option.
(Closes: #974988)
* Modernize server package description.
* Use xsltproc --nonet.
* run-testsuite: Test only this version.
[ Helmut Grohne ]
* Reduce Build-Depends: (Closes: #979456)
+ gdb is only used for testing.
-- Christoph Berg <email address hidden> Wed, 10 Feb 2021 17:33:55 +0100
