New upstream microreleases 12.15, 14.8, and 15.3

Bug #2019214 reported by Athos Ribeiro
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
postgresql-12 (Ubuntu)
Focal
Fix Released
Undecided
Sergio Durigan Junior
postgresql-14 (Ubuntu)
Jammy
Fix Released
Undecided
Athos Ribeiro
Kinetic
Fix Released
Undecided
Athos Ribeiro
postgresql-15 (Ubuntu)
Status tracked in Mantic
Lunar
Fix Released
Undecided
Sergio Durigan Junior
Mantic
Fix Released
Undecided
Sergio Durigan Junior

Bug Description

[Impact]

 * MRE for latest stable fixes of Postgres 12, 14, and 15 released on May 2023.

[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]

 * Upstreams tests are usually great and in additon 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 hickups (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-2023-2454
   - CVE-2023-2455

Current versions in supported releases that got updates:
 postgresql-12 | 12.14-0ubuntu0.20.04.1 | focal-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.7-0ubuntu0.22.04.1 | jammy-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.7-0ubuntu0.22.10.1 | kinetic-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-15 | 15.2-1 | lunar | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Mantic will not sync from Debian as it usually happens since Debian is going through a freeze.

Standing MRE - Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676
- pad.lv/1752271
- pad.lv/1786938
- pad.lv/1815665
- pad.lv/1828012
- pad.lv/1833211
- pad.lv/1839058
- pad.lv/1863108
- pad.lv/1892335
- pad.lv/1915254
- pad.lv/1928773
- pad.lv/1939396
- pad.lv/1950268
- pad.lv/1961127
- pad.lv/1973627
- pad.lv/1978249
- pad.lv/1984012
- pad.lv/1996770
- pad.lv/2006406

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

Tags: server-todo

Related branches

CVE References

tags: added: server-todo
description: updated
description: updated
Changed in postgresql-12 (Ubuntu Focal):
assignee: nobody → Sergio Durigan Junior (sergiodj)
Changed in postgresql-15 (Ubuntu Lunar):
assignee: nobody → Sergio Durigan Junior (sergiodj)
Changed in postgresql-14 (Ubuntu Jammy):
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Changed in postgresql-14 (Ubuntu Kinetic):
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

This bug was fixed in the package postgresql-15 - 15.3-1

---------------
postgresql-15 (15.3-1) experimental; urgency=medium

  * New upstream version.

    + Prevent CREATE SCHEMA from defeating changes in search_path
      (Report and fix by Alexander Lakhin, CVE-2023-2454)

      Within a CREATE SCHEMA command, objects in the prevailing search_path,
      as well as those in the newly-created schema, would be visible even
      within a called function or script that attempted to set a secure
      search_path. This could allow any user having permission to create a
      schema to hijack the privileges of a security definer function or
      extension script.

    + Enforce row-level security policies correctly after inlining a
      set-returning function (Report by Wolfgang Walther, CVE-2023-2455)

      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling query,
      those RLS policies would not get enforced properly in some cases
      involving re-using a cached plan under a different role. This could
      allow a user to see or modify rows that should have been invisible.

  * Reenable JIT on s390x using workaround patch from SUSE.

 -- Christoph Berg <email address hidden> Tue, 09 May 2023 19:05:02 +0200

Changed in postgresql-15 (Ubuntu Mantic):
assignee: nobody → Sergio Durigan Junior (sergiodj)
Changed in postgresql-15 (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

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

  * New upstream version (LP: #2019214).

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

    + Also, if you are upgrading from a version earlier than 12.10, see
      those release notes as well please.

    + Prevent CREATE SCHEMA from defeating changes in search_path
      (Alexander Lakhin)

      Within a CREATE SCHEMA command, objects in the prevailing
      search_path, as well as those in the newly-created schema, would be
      visible even within a called function or script that attempted to set
      a secure search_path. This could allow any user having permission to
      create a schema to hijack the privileges of a security definer
      function or extension script.
      (CVE-2023-2454)

    + Enforce row-level security policies correctly after inlining a
      set-returning function (Stephen Frost, Tom Lane)

      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling
      query, those RLS policies would not get enforced properly in some
      cases involving re-using a cached plan under a different role. This
      could allow a user to see or modify rows that should have been
      invisible.
      (CVE-2023-2455)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/12/release-12-15.html.

 -- Sergio Durigan Junior <email address hidden> Thu, 11 May 2023 15:58:10 -0400

Changed in postgresql-12 (Ubuntu Focal):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-15 - 15.3-0ubuntu0.23.04.1

---------------
postgresql-15 (15.3-0ubuntu0.23.04.1) lunar-security; urgency=medium

  * New upstream version (LP: #2019214).

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

    + Also, if you are upgrading from a version earlier than 15.1, see
      those release notes as well please.

    + Prevent CREATE SCHEMA from defeating changes in search_path
      (Alexander Lakhin)

      Within a CREATE SCHEMA command, objects in the prevailing
      search_path, as well as those in the newly-created schema, would be
      visible even within a called function or script that attempted to set
      a secure search_path. This could allow any user having permission to
      create a schema to hijack the privileges of a security definer
      function or extension script.
      (CVE-2023-2454)

    + Enforce row-level security policies correctly after inlining a
      set-returning function (Stephen Frost, Tom Lane)

      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling
      query, those RLS policies would not get enforced properly in some
      cases involving re-using a cached plan under a different role. This
      could allow a user to see or modify rows that should have been
      invisible.
      (CVE-2023-2455)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/15/release-15-3.html.

 -- Sergio Durigan Junior <email address hidden> Thu, 11 May 2023 16:24:27 -0400

Changed in postgresql-15 (Ubuntu Lunar):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

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

  * New upstream version (LP: #2019214).

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

    + Also, if you are upgrading from a version earlier than 14.4, see
      those release notes as well please.

    + Prevent CREATE SCHEMA from defeating changes in search_path
      (Alexander Lakhin)

      Within a CREATE SCHEMA command, objects in the prevailing
      search_path, as well as those in the newly-created schema, would be
      visible even within a called function or script that attempted to set
      a secure search_path. This could allow any user having permission to
      create a schema to hijack the privileges of a security definer
      function or extension script.
      (CVE-2023-2454)

    + Enforce row-level security policies correctly after inlining a
      set-returning function (Stephen Frost, Tom Lane)

      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling
      query, those RLS policies would not get enforced properly in some
      cases involving re-using a cached plan under a different role. This
      could allow a user to see or modify rows that should have been
      invisible.
      (CVE-2023-2455)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/14/release-14-8.html

 -- Athos Ribeiro <email address hidden> Tue, 16 May 2023 09:37:37 -0300

Changed in postgresql-14 (Ubuntu Jammy):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-14 - 14.8-0ubuntu0.22.10.1

---------------
postgresql-14 (14.8-0ubuntu0.22.10.1) kinetic-security; urgency=medium

  * New upstream version (LP: #2019214).

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

    + Also, if you are upgrading from a version earlier than 14.4, see
      those release notes as well please.

    + Prevent CREATE SCHEMA from defeating changes in search_path
      (Alexander Lakhin)

      Within a CREATE SCHEMA command, objects in the prevailing
      search_path, as well as those in the newly-created schema, would be
      visible even within a called function or script that attempted to set
      a secure search_path. This could allow any user having permission to
      create a schema to hijack the privileges of a security definer
      function or extension script.
      (CVE-2023-2454)

    + Enforce row-level security policies correctly after inlining a
      set-returning function (Stephen Frost, Tom Lane)

      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling
      query, those RLS policies would not get enforced properly in some
      cases involving re-using a cached plan under a different role. This
      could allow a user to see or modify rows that should have been
      invisible.
      (CVE-2023-2455)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/14/release-14-8.html

 -- Athos Ribeiro <email address hidden> Tue, 16 May 2023 09:10:45 -0300

Changed in postgresql-14 (Ubuntu Kinetic):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.