New PostgreSQL upstream microreleases 14.17 and 16.8

[Athos Ribeiro]

[Impact]

 * MRE for latest stable fixes of Postgres 14 and 16 released on February 2025.

[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-2025-1094

Current versions in supported releases that got updates:

 postgresql-14 | 14.15-0ubuntu0.22.04.1 | jammy-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.6-0ubuntu0.24.04.1 | noble-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.6-0ubuntu0.24.10.1 | oracular-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Since there is one CVE being fixed here, we will push these MREs through the security pocket.
- Plucky alrady sync'd 17.4 with from Debian, which contains those fixes as well.

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
- https://pad.lv/2085196

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

[Athos Ribeiro (athos)]

The packages are ready in the PPA.

The security team will take over from here and push them to the security pocket.

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #2099900).

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

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #2099900).

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

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

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

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #2099900).

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

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

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