[ubuntu/trusty-security] postgresql-9.3 9.3.18-0ubuntu0.14.04.1 (Accepted)

Marc Deslauriers marc.deslauriers at canonical.com
Tue Aug 15 16:46:29 UTC 2017

postgresql-9.3 (9.3.18-0ubuntu0.14.04.1) trusty-security; urgency=medium

  * SECURITY UPDATE: Update to 9.3.18 to fix security issues
    - Further restrict visibility of pg_user_mappings.umoptions, to protect
      passwords stored as user mapping options (CVE-2017-7547)
    - Disallow empty passwords in all password-based authentication methods
    - Make lo_put() check for UPDATE privilege on the target large object

postgresql-9.3 (9.3.17-0ubuntu0.14.04) trusty; urgency=medium

  * New upstream release (LP: #1690730)
    - Restrict visibility of pg_user_mappings.umoptions, to protect passwords
      stored as user mapping options (CVE-2017-7486)
    - Prevent exposure of statistical information via leaky operators
    - Restore libpq's recognition of the PGREQUIRESSL environment variable

    - A dump/restore is not required for those running 9.3.X.
    - However, if you use foreign data servers that make use of user passwords
      for authentication, see the first changelog entry.

    - Details about other changes at full changelog:

postgresql-9.3 (9.3.16-0ubuntu0.14.04) trusty; urgency=medium

  * New upstream release (LP: #1664478)
    - Fix a race condition that could cause indexes built with CREATE INDEX
      CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane).
      If CREATE INDEX CONCURRENTLY was used to build an index that depends on
      a column not previously indexed, then rows inserted or updated by
      transactions that ran concurrently with the CREATE INDEX command could
      have received incorrect index entries.  If you suspect this may have
      happened, the most reliable solution is to rebuild affected indexes
      after installing this update

    - Details about other changes:

postgresql-9.3 (9.3.15-0ubuntu0.14.04) trusty-proposed; urgency=medium

  * New upstream bug fix release (LP: #1637236)
    - Fix WAL-logging of truncation of relation free space maps and visibility
      It was possible for these files to not be correctly restored during
      crash recovery, or to be written incorrectly on a standby server. Bogus
      entries in a free space map could lead to attempts to access pages that
      have been truncated away from the relation itself, typically producing
      errors like "could not read block XXX: read only 0 of 8192 bytes".
      Checksum failures in the visibility map are also possible, if
      checksumming is enabled.

      Procedures for determining whether there is a problem and repairing it
      if so are discussed at

    - Details about other changes:

Date: 2017-08-14 15:25:14.578921+00:00
Changed-By: Marc Deslauriers <marc.deslauriers at canonical.com>
-------------- next part --------------
Sorry, changesfile not available.

More information about the Trusty-changes mailing list