New PostgreSQL upstream microreleases 12.22, 14.15 and 16.6

[Bryce Harrington]

[Impact]

 * MRE for latest stable fixes of Postgres 12, 14, and 16 released on November 2024.

[Test Case]

 * The Postgres MREs traditionally rely on the large set of autopkgtests
   to run for verification. In a PPA, those are all already pre-checked to
   be good for this upload.

[Regression Potential]

 * Upstream tests are usually great and in addition in the Archive there
   are plenty of autopkgtests that in the past caught issues before being
   released.
   But nevertheless there always is a risk for something to break. Since
   these are general stable releases I can't pinpoint them to a most-likely area.
   - usually this works smoothly except a few test hiccups (flaky) that need to be clarified to be sure. Pre-checks will catch those to be discussed upfront (as last time)

[Other Info]

 * This is a reoccurring MRE, see below and all the references
 * CVEs addressed by this MRE:
  - CVE-2024-10976
  - CVE-2024-10977
  - CVE-2024-10978
  - CVE-2024-10979

Current versions in supported releases that got updates:

 postgresql-12 | 12.20-0ubuntu0.20.04.1 | focal-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.13-0ubuntu0.22.04.1 | jammy-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.4-0ubuntu0.24.04.2 | noble-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.4-1build1 | oracular | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Since there are 4 CVEs being fixed here, we will push these MREs through the security pocket.
- Plucky will sync from Debian

Standing MRE - Consider last updates as template:

- https://pad.lv/1637236
- https://pad.lv/1664478
- https://pad.lv/1690730
- https://pad.lv/1713979
- https://pad.lv/1730661
- https://pad.lv/1747676
- https://pad.lv/1752271
- https://pad.lv/1786938
- https://pad.lv/1815665
- https://pad.lv/1828012
- https://pad.lv/1833211
- https://pad.lv/1839058
- https://pad.lv/1863108
- https://pad.lv/1892335
- https://pad.lv/1915254
- https://pad.lv/1928773
- https://pad.lv/1939396
- https://pad.lv/1950268
- https://pad.lv/1961127
- https://pad.lv/1973627
- https://pad.lv/1978249
- https://pad.lv/1984012
- https://pad.lv/1996770
- https://pad.lv/2006406
- https://pad.lv/2019214
- https://pad.lv/2028426
- https://pad.lv/2040469
- https://pad.lv/2067388
- https://pad.lv/2076183

As usual we test and prep from the PPA and then push through SRU/Security as applicable.

Once ready, the test packages should be available at https://launchpad.net/~canonical-server/+archive/ubuntu/postgresql-sru-preparation/+packages

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Athos Ribeiro (athos)]

Thanks, Sergio. I reviewed all merge proposals linked to this bug.
The new source contents are sound, and the packages in your PPA matches the MPs.
The changelog entries look great!

I do have the following comments on them:

- In the Oracular MP, the debian/postgresql-16.NEWS file has the wrong version in it (it mentions the noble entry).
- In the Jammy MP, the new entry in the debian/postgresql-14.NEWS file is missing the last line with the Author information.

Other than that, they all LGTM :)

[Sergio Durigan Junior (sergiodj)]

Thanks, Athos.

I've addressed all your comments and reuploaded all packages to the PPA. The Security team has been notified and can act on them as soon as they have the cycles to do so.

Cheers.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-12 - 12.22-0ubuntu0.20.04.1

---------------
postgresql-12 (12.22-0ubuntu0.20.04.1) focal-security; urgency=medium

  * New upstream version (LP: #2085196).

    + This release encompasses changes from upstream's 12.21 and 12.22
      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 12.21.

    + A dump/restore is not required for those running 12.X.

    + However, if you are upgrading from a version earlier than 12.18, 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 arbitrar...

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-16 - 16.6-0ubuntu0.24.04.1

---------------
postgresql-16 (16.6-0ubuntu0.24.04.1) noble-security; urgency=medium

  * New upstream version (LP: #2085196).

    + This release encompasses changes from upstream's 16.5 and 16.6
      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 16.5.

    + A dump/restore is not required for those running 16.X.

    + However, if you are upgrading from a version earlier than 16.3, 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...

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-14 - 14.15-0ubuntu0.22.04.1

---------------
postgresql-14 (14.15-0ubuntu0.22.04.1) jammy-security; urgency=medium

  * New upstream version (LP: #2085196).

    + 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 arbitrar...

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-16 - 16.6-0ubuntu0.24.10.1

---------------
postgresql-16 (16.6-0ubuntu0.24.10.1) oracular-security; urgency=medium

  * New upstream version (LP: #2085196).

    + This release encompasses changes from upstream's 16.5 and 16.6
      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 16.5.

    + A dump/restore is not required for those running 16.X.

    + However, if you are upgrading from a version earlier than 16.3, 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 c...