postgresql-14 (14.18-0ubuntu0.22.04.1) jammy; urgency=medium
A dump/restore is not required for those running 14.X.
However, if you have any self-referential foreign key constraints on
partitioned tables, it may be necessary to recreate those constraints to
ensure that they are being enforced correctly. Follow the steps below to
do so.
Also, if you have any BRIN bloom indexes, it may be advisable to reindex
them after updating. Follow the steps below to do so.
Also, if you are upgrading from a version earlier than 14.14, see those
release notes as well please.
Avoid one-byte buffer overread when examining invalidly-encoded strings
that are claimed to be in GB18030 encoding (Noah Misch, Andres Freund)
While unlikely, a SIGSEGV crash could occur if an incomplete multibyte
character appeared at the end of memory. This was possible both in the
server and in libpq-using applications. (CVE-2025-4207)
Handle self-referential foreign keys on partitioned tables correctly
(Álvaro Herrera)
Creating or attaching partitions failed to make the required catalog
entries for a foreign-key constraint, if the table referenced by the
constraint was the same partitioned table. This resulted in failure to
enforce the constraint fully.
To fix this, you should drop and recreate any self-referential foreign
keys on partitioned tables, if partitions have been created or attached
since the constraint was created. Bear in mind that violating rows might
already be present, in which case recreating the constraint will fail,
and you'll need to fix up those rows before trying again.
Avoid data loss when merging compressed BRIN summaries in
brin_bloom_union() (Tomas Vondra)
The code failed to account for decompression results not being identical
to the input objects, which would result in failure to add some of the
data to the merged summary, leading to missed rows in index searches.
This mistake was present back to v14 where BRIN bloom indexes were
introduced, but this code path was only rarely reached then. It's
substantially more likely to be hit in v17 because parallel index builds
now use the code.
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-18.html.
-- Athos Ribeiro <athos.ribeiro@canonical.com> Sun, 11 May 2025 06:17:40 -0300
postgresql-14 (14.17-0ubuntu0.22.04.1) jammy; urgency=medium
This release encompasses changes from upstream's 14.16 and 14.17
releases. The former contains fixes for CVE-2025-1094 (among other
things), and the latter was a hotfix for a problem caused by the CVE
fix from 14.16.
A dump/restore is not required for those running 14.X.
However, if you are upgrading from a version earlier than 14.14, see
those release notes as well please.
Harden PQescapeString and allied functions against invalidly-encoded
input strings (Andres Freund, Noah Misch)
Data-quoting functions supplied by libpq now fully check the encoding
validity of their input. If invalid characters are detected, they report
an error if possible. For the ones that lack an error return convention,
the output string is adjusted to ensure that the server will report
invalid encoding and no intervening processing will be fooled by bytes
that might happen to match single quote, backslash, etc.
The purpose of this change is to guard against SQL-injection attacks
that are possible if one of these functions is used to quote crafted
input. There is no hazard when the resulting string is sent directly to
a PostgreSQL server (which would check its encoding anyway), but there
is a risk when it is passed through psql or other client-side code.
Historically such code has not carefully vetted encoding, and in many
cases it's not clear what it should do if it did detect such a problem.
This fix is effective only if the data-quoting function, the server, and
any intermediate processing agree on the character encoding that's being
used. Applications that insert untrusted input into SQL commands should
take special care to ensure that that's true.
Applications and drivers that quote untrusted input without using these
libpq functions may be at risk of similar problems. They should first
confirm the data is valid in the encoding expected by the server.
The PostgreSQL Project thanks Stephen Fewer for reporting this problem.
(CVE-2025-1094)
Improve behavior of libpq's quoting functions (Andres Freund, Tom Lane)
The changes made for CVE-2025-1094 had one serious oversight:
PQescapeLiteral() and PQescapeIdentifier() failed to honor their string
length parameter, instead always reading to the input string's trailing
null. This resulted in including unwanted text in the output, if the
caller intended to truncate the string via the length parameter. With
very bad luck it could cause a crash due to reading off the end of
memory.
In addition, modify all these quoting functions so that when invalid
encoding is detected, an invalid sequence is substituted for just the
first byte of the presumed character, not all of it. This reduces the
risk of problems if a calling application performs additional processing
on the quoted string.
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-16.html and
https://www.postgresql.org/docs/14/release-14-17.html.
-- Athos Ribeiro <athos.ribeiro@canonical.com> Mon, 24 Feb 2025 13:01:54 -0300
postgresql-14 (14.15-0ubuntu0.22.04.1) jammy; urgency=medium
This release encompasses changes from upstream's 14.14 and 14.15
releases. The former contains fixes for 4 CVEs (among other
things), and the latter was hotfix for a problem caused by one of
the CVE fixes from 14.14.
A dump/restore is not required for those running 14.X.
However, if you are upgrading from a version earlier than 14.12, see
those release notes as well please.
Ensure cached plans are marked as dependent on the calling role when
RLS applies to a non-top-level table reference (Nathan Bossart)
If a CTE, subquery, sublink, security invoker view, or coercion
projection in a query references a table with row-level security
policies, we neglected to mark the resulting plan as potentially
dependent on which role is executing it. This could lead to later query
executions in the same session using the wrong plan, and then returning
or hiding rows that should have been hidden or returned instead.
The PostgreSQL Project thanks Wolfgang Walther for reporting this
problem.
(CVE-2024-10976)
Make libpq discard error messages
received during SSL or GSS protocol negotiation (Jacob Champion)
An error message received before encryption negotiation is completed
might have been injected by a man-in-the-middle, rather than being real
server output. Reporting it opens the door to various security hazards;
for example, the message might spoof a query result that a careless user
could mistake for correct output. The best answer seems to be to
discard such data and rely only on libpq's own report of the connection
failure.
The PostgreSQL Project thanks Jacob Champion for reporting this
problem.
(CVE-2024-10977)
Fix unintended interactions between SET SESSION AUTHORIZATION
and SET ROLE (Tom Lane)
The SQL standard mandates that SET SESSION AUTHORIZATION have a
side-effect of doing SET ROLE NONE. Our implementation of that was
flawed, creating more interaction between the two settings than
intended. Notably, rolling back a transaction that had done SET SESSION
AUTHORIZATION would revert ROLE to NONE even if that had not been the
previous state, so that the effective user ID might now be different
from what it had been before the transaction. Transiently setting
session_authorization in a function SET clause had a similar effect. A
related bug was that if a parallel worker inspected
current_setting('role'), it saw none even when it should see something
else.
The PostgreSQL Project thanks Tom Lane for reporting this problem.
(CVE-2024-10978)
Prevent trusted PL/Perl code from changing environment variables
(Andrew Dunstan, Noah Misch)
The ability to manipulate process environment variables such as PATH
gives an attacker opportunities to execute arbitrary code. Therefore,
trustedPLs must not offer the ability to do that. To fix plperl,
replace %ENV with a tied hash that rejects any modification attempt with
a warning. Untrusted plperlu retains the ability to change the
environment.
The PostgreSQL Project thanks Coby Abrams for reporting this problem.
(CVE-2024-10979)
Restore functionality of ALTER {ROLE|DATABASE} SET
role (Tom Lane, Noah Misch)
The fix for CVE-2024-10978 accidentally caused settings for role to
not be applied if they come from non-interactive sources, including
previous ALTER {ROLE|DATABASE} commands and the PGOPTIONS environment
variable.
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-14.html and
https://www.postgresql.org/docs/14/release-14-15.html.
-- Sergio Durigan Junior <sergio.durigan@canonical.com> Mon, 25 Nov 2024 16:05:41 -0500
postgresql-14 (14.13-0ubuntu0.22.04.1) jammy; urgency=medium
A dump/restore is not required for those running 14.X.
However, if you are upgrading from a version earlier than 14.12, see
those release notes as well please.
Prevent unauthorized code execution during pg_dump (Masahiko Sawada)
An attacker able to create and drop non-temporary objects could inject
SQL code that would be executed by a concurrent pg_dump session with the
privileges of the role running pg_dump (which is often a superuser).
The attack involves replacing a sequence or similar object with a view
or foreign table that will execute malicious code. To prevent this,
introduce a new server parameter restrict_nonsystem_relation_kind that
can disable expansion of non-builtin views as well as access to foreign
tables, and teach pg_dump to set it when available. Note that the
attack is prevented only if both pg_dump and the server it is dumping
from are new enough to have this fix.
The PostgreSQL Project thanks Noah Misch for reporting this problem.
(CVE-2024-7348)
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-13.html.
-- Athos Ribeiro <athos.ribeiro@canonical.com> Tue, 06 Aug 2024 15:36:29 -0300
postgresql-14 (14.12-0ubuntu0.22.04.1) jammy; urgency=medium
A dump/restore is not required for those running 14.X.
However, a security vulnerability was found in the system views
pg_stats_ext and pg_stats_ext_exprs, potentially allowing
authenticated database users to see data they shouldn't. If this is of
concern in your installation, follow the steps below to rectify it.
These views failed to hide statistics for expressions that involve
columns the accessing user does not have permission to read. View
columns such as most_common_vals might expose security-relevant
data. The potential interactions here are not fully clear, so in the
interest of erring on the side of safety, make rows in these views
visible only to the owner of the associated table.
By itself, this fix will only fix the behavior in newly initdb'd
database clusters. If you wish to apply this change in an existing
cluster, you will need to do the following:
- In each database of the cluster, run the
/usr/share/postgresql/14/fix-CVE-2024-4317.sql script as superuser. In
psql this would look like:
\i /usr/share/postgresql/14/fix-CVE-2024-4317.sql
It will not hurt to run the script more than once.
- Do not forget to include the template0 and template1 databases,
or the vulnerability will still exist in databases you create
later. To fix template0, you'll need to temporarily make it accept
connections. Do that with:
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
and then after fixing template0, undo it with:
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
Also, if you are upgrading from a version earlier than 14.11, see
those release notes as well please.
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-12.html
-- Sergio Durigan Junior <sergio.durigan@canonical.com> Tue, 28 May 2024 09:51:10 -0400
postgresql-14 (14.11-0ubuntu0.22.04.1) jammy; urgency=medium
A dump/restore is not required for those running 14.X.
However, one bug was fixed that could have resulted in corruption of
GIN indexes during concurrent updates. If you suspect such
corruption, reindex affected indexes after installing this update.
Also, if you are upgrading from a version earlier than 14.10, see
those release notes as well please.
Details about these and many further changes can be found at:
https://www.postgresql.org/docs/14/release-14-11.html
-- Sergio Durigan Junior <sergio.durigan@canonical.com> Fri, 09 Feb 2024 19:49:08 -0500
Generated by dwww version 1.14 on Sat Sep 6 16:16:23 CEST 2025.