New upstream microreleases 10.21, 12.11, 13.7 and 14.3

Bug #1973627 reported by Athos Ribeiro
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
postgresql-10 (Ubuntu)
Invalid
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned
postgresql-12 (Ubuntu)
Invalid
Undecided
Unassigned
Focal
Fix Released
Undecided
Unassigned
postgresql-13 (Ubuntu)
Invalid
Undecided
Unassigned
Impish
Fix Released
Undecided
Athos Ribeiro
postgresql-14 (Ubuntu)
Fix Released
Undecided
Athos Ribeiro
Jammy
Fix Released
Undecided
Athos Ribeiro

Bug Description

[Impact]

 * MRE for latest stable fixes of Postgres released in May 2022

[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 catched 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 for 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 this time:
   - CVE-2022-1552 (v10, v12, v13, v14)

Current versions in supported releases that got updates:
 postgresql-10 | 10.20-0ubuntu0.18.04.1 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x
 postgresql-12 | 12.10-0ubuntu0.20.04.1 | focal-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-13 | 13.6-0ubuntu0.21.10.1 | impish-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.2-1ubuntu1 | jammy | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Kinetic has already synced from Debian as usual (14.3).

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

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

Related branches

CVE References

Changed in postgresql-14 (Ubuntu):
status: New → Fix Committed
no longer affects: postgresql-13 (Ubuntu Jammy)
no longer affects: postgresql-14 (Ubuntu Bionic)
no longer affects: postgresql-13 (Ubuntu Bionic)
no longer affects: postgresql-12 (Ubuntu Bionic)
Changed in postgresql-10 (Ubuntu):
status: New → Invalid
no longer affects: postgresql-10 (Ubuntu Focal)
no longer affects: postgresql-10 (Ubuntu Impish)
no longer affects: postgresql-14 (Ubuntu Focal)
no longer affects: postgresql-14 (Ubuntu Impish)
no longer affects: postgresql-13 (Ubuntu Focal)
no longer affects: postgresql-12 (Ubuntu Impish)
Changed in postgresql-14 (Ubuntu):
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Changed in postgresql-13 (Ubuntu):
status: New → Invalid
Changed in postgresql-12 (Ubuntu):
status: New → Invalid
tags: added: server-todo
Changed in postgresql-14 (Ubuntu Jammy):
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Changed in postgresql-13 (Ubuntu Impish):
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-10 - 10.21-0ubuntu0.18.04.1

---------------
postgresql-10 (10.21-0ubuntu0.18.04.1) bionic-security; urgency=medium

  * New upstream version (LP: #1973627).

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

    + However, if you are upgrading from a version earlier than 10.19, 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/10/release-10-21.html

 -- Sergio Durigan Junior <email address hidden> Tue, 17 May 2022 21:58:23 -0400

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

This bug was fixed in the package postgresql-13 - 13.7-0ubuntu0.21.10.1

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

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

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

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

  * New upstream version (LP: #1973627).

    + A dump/restore is not required for those running 14.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 14.2, 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/14/release-14-3.html

  * d/p/llvm14-support.patch: drop patch applied upstream.

 -- Athos Ribeiro <email address hidden> Mon, 16 May 2022 16:17:01 -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-12 - 12.11-0ubuntu0.20.04.1

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

  * New upstream version (LP: #1973627)

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

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

    + 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/12/release-12-11.html

 -- Sergio Durigan Junior <email address hidden> Tue, 17 May 2022 22:10:51 -0400

Changed in postgresql-12 (Ubuntu Focal):
status: New → Fix Released
Changed in postgresql-14 (Ubuntu):
status: Fix Committed → Fix Released
tags: added: needs-mre-backport
removed: server-todo
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