New upstream microreleases 10.17 12.7 13.3

Bug #1928773 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
postgresql-10 (Ubuntu)
Bionic
Fix Released
Undecided
Unassigned
postgresql-12 (Ubuntu)
Invalid
Undecided
Unassigned
Focal
Fix Released
Undecided
Unassigned
Groovy
Fix Released
Undecided
Unassigned
postgresql-13 (Ubuntu)
Hirsute
Fix Released
Undecided
Unassigned
Impish
Fix Released
Undecided
Unassigned

Bug Description

[Impact]

 * MRE for latest stable fixes of Postgres released on May 2021

[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 catched issues before being
   released.
   But never the less 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
 * This includes a fix for one CVE:
    CVE-2021-3393 - only v12 for on Focal/Groovy

---

Current versions in supported releases that got updates:
 postgresql-13 | 13.2-1 | hirsute | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-12 | 12.6-0ubuntu0.20.10.1 | groovy-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-12 | 12.6-0ubuntu0.20.04.1 | focal-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-10 | 10.16-0ubuntu0.18.04.1 | bionic-security | source, amd64, arm64, armhf, i386, ppc64el, s390x

No new version for:
 postgresql-9.5 | 9.5.25-0ubuntu0.16.04.1 | xenial-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x

Special cases:
- Impish is already synced from Debian.

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

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

Changed in postgresql-12 (Ubuntu):
status: New → Invalid
no longer affects: postgresql-10 (Ubuntu Impish)
Changed in postgresql-13 (Ubuntu Impish):
status: New → Fix Released
Changed in postgresql-13 (Ubuntu Hirsute):
status: New → In Progress
Changed in postgresql-12 (Ubuntu Groovy):
status: New → In Progress
Changed in postgresql-12 (Ubuntu Focal):
status: New → In Progress
Changed in postgresql-10 (Ubuntu Bionic):
status: New → In Progress
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

PPA builds and tests ran:
Bionic - https://bileto.ubuntu.com/#/ticket/4555
Focal - https://bileto.ubuntu.com/#/ticket/4556
Groovy - https://bileto.ubuntu.com/#/ticket/4557
Hirsute - https://bileto.ubuntu.com/#/ticket/4558

Of those Focal-Hirsute look all good to me.

Bionic is a bit problematic with reproducible issues (only on armhf) that have to be checked in detail. Affected tests are:
- postgis
- postgresql-10
- psqlodbc
- slony1-2

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Of the above
- postgis
- psqlodbc
- slony1-2

All fail on:
/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.o2j3Z4: Permission denied

- postgresql-10

# Failed test 'default log is not used'
# at ./t/020_create_sql_remove.t line 133.
not ok 31 - default log is not used
...
not ok 36 - default log is not used

Neither of those seem obviously arch-dependent to only occur on armhf.
I'll have to go to canonistack with that.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI postgresql-10 resolved, it was just flaky after all.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Manual checks on armhf in canonistack

Test: postgis (but slony and psqlodbc have the exact same error)
1. installing dependencies (works as in the autopkgtest)
2. check pg_buildext supported-versions
  => 10
  ok that works and is as expected
3. + pg_virtualenv -v 10 sh -e
/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.gJU4VI: Permission denied

So the virtualenv call has the issue as it was expected from the permission error already.
^^ This happens as-is without anything from my PPAs or proposed.

This file is generated like:
    PWFILE=$(mktemp -t pgpassword.XXXXXX)
    chown postgres:postgres "$PWFILE"
And at the time of the error it is like:
-rw------- 1 postgres postgres 0 May 31 13:35 /tmp/pgpassword.fCpFSb

Since the test runs as root that access fails.
This isn't a problem with the new postgresql that we have prepared.
This was later made more resilent in https://salsa.debian.org/postgresql/postgresql-common/-/commit/aa4829c899a3cf7ea6c90990d989dd57d2a63857

As soon as that permission issue is fixed (in the manual test) then it runs fine.

All that seems to make sense, the one puzzling part that remains why has this ever worked https://autopkgtest.ubuntu.com/packages/p/postgis/bionic/armhf ?

The permissions set by mktemp in src:coreutils are 0600 (file) and 0700 (dir) for ages.
And there as no change to the package in bionic since 18 Jan 2018.

I've also ran the slony and psqlodbc tests - both worked fine.
So we can release these builds but need to consider backporting the password fix.
=> that will be covered via an MP to the test hints

Changed in postgresql-13 (Ubuntu Hirsute):
status: In Progress → Fix Committed
Changed in postgresql-12 (Ubuntu Groovy):
status: In Progress → Triaged
status: Triaged → Fix Committed
Changed in postgresql-12 (Ubuntu Focal):
status: In Progress → Fix Committed
Changed in postgresql-10 (Ubuntu Bionic):
status: In Progress → Fix Committed
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

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

  * New upstream version (LP: #1928773).

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

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:17:37 +0200

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

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

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

  * New upstream version (LP: #1928773).

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

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:13:14 +0200

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

This bug was fixed in the package postgresql-13 - 13.3-0ubuntu0.21.04.1

---------------
postgresql-13 (13.3-0ubuntu0.21.04.1) hirsute-security; urgency=medium

  * New upstream version (LP: #1928773).

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

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:06:38 +0200

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

This bug was fixed in the package postgresql-12 - 12.7-0ubuntu0.20.10.1

---------------
postgresql-12 (12.7-0ubuntu0.20.10.1) groovy-security; urgency=medium

  * New upstream version (LP: #1928773).

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

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:13:14 +0200

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

Other bug subscribers