Changeset ab83f2b4bb changed the startup order for Postgresql. The cleartmp
rc.d now comes after the Postgresql startup. Unfortunately, Postgresql likes
to create a socket in /tmp/.s.PGSQL.5432. After cleartmp does its work, that
socket disappears from the filesystem.
Submitted by: Jeroen Pulles
PR: 256335
PostgreSQL 13.3, 12.7, 11.12, 10.17, and 9.6.22 Released!
The PostgreSQL Global Development Group has released an update to all supported
versions of our database system, including 13.3, 12.7, 11.12, 10.17, and
9.6.22. This release closes three security vulnerabilities and fixes over 45
bugs reported over the last three months.
Security fixes in this release:
CVE-2021-32027: Buffer overrun from integer overflow in array subscripting
calculations
CVE-2021-32028: Memory disclosure in INSERT ... ON CONFLICT ... DO UPDATE
CVE-2021-32029: Memory disclosure in partitioned-table UPDATE ... RETURNING
Also plenty of bug fixes. See the release note for details.
Changes to the port:
Make sure we use the matching version of llvm. This fixes a problem with the
llvm version string not being monotonically increasing with the version
number. [1]
Better pkg message about checksums for postgresql 12+. [2] [4]
Adjust login class parameter to adhere to the documentation in rc.subr(8) [3]:
The rc.conf parameter for the login class of the postgresql daemon has
changed name from postgresql_class to postgresql_login_class, since
rc.subr(8) states that the parameter should be named ${name}_login_class.
Allow parallel builds. [5]
Correct the directory name for the user postgres in pkg message. [6]
PR: 250824 [1], 253558 [2], 236060 [3], 233106 [4], 230656 [5]
PR: 226674 [6]
Submitted by: Michael Zhilin [2], Michael Zhilin [3], Dmitry Chestnykh [4]
Submitted by: Steve Wills [5], knezour [6]
Security: 76e0bb86-b4cb-11eb-b9c9-6cc21735f730
Security: 62da9702-b4cc-11eb-b9c9-6cc21735f730
Release notes: https://www.postgresql.org/docs/release/
supported versions of our database system, including 11.5, 10.10,
9.6.15, 9.5.19, and 9.4.24, as well as the third beta of PostgreSQL 12.
This release fixes two security issues in the PostgreSQL server, two
security issues found in one of the PostgreSQL Windows installers, and
over 40 bugs reported since the previous release.
Users should install these updates as soon as possible.
A Note on the PostgreSQL 12 Beta
================================
In the spirit of the open source PostgreSQL community, we strongly
encourage you to test the new features of PostgreSQL 12 in your database
systems to help us eliminate any bugs or other issues that may exist.
While we do not advise you to run PostgreSQL 12 Beta 3 in your
production environments, we encourage you to find ways to run your
typical application workloads against this beta release.
Your testing and feedback will help the community ensure that the
PostgreSQL 12 release upholds our standards of providing a stable,
reliable release of the world's most advanced open source relational
database.
Security Issues
===============
Two security vulnerabilities have been closed by this release:
* CVE-2019-10208: `TYPE` in `pg_temp` executes arbitrary SQL during
`SECURITY DEFINER` execution
Versions Affected: 9.4 - 11
Given a suitable `SECURITY DEFINER` function, an attacker can execute
arbitrary SQL under the identity of the function owner. An attack
requires `EXECUTE` permission on the function, which must itself contain
a function call having inexact argument type match. For example,
`length('foo'::varchar)` and `length('foo')` are inexact, while
`length('foo'::text)` is exact. As part of exploiting this
vulnerability, the attacker uses `CREATE DOMAIN` to create a type in a
`pg_temp` schema. The attack pattern and fix are similar to that for
CVE-2007-2138.
Writing `SECURITY DEFINER` functions continues to require following the
considerations noted in the documentation:
https://www.postgresql.org/docs/devel/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY
The PostgreSQL project thanks Tom Lane for reporting this problem.
* CVE-2019-10209: Memory disclosure in cross-type comparison for hashed
subplan
Versions Affected: 11
In a database containing hypothetical, user-defined hash equality operators, an attacker could read arbitrary bytes of server memory. For an attack to become possible, a superuser would need to create unusual operators. It is possible for operators not purpose-crafted for attack to have the properties that enable an attack, but we are not aware of specific examples.
The PostgreSQL project thanks Andreas Seltenreich for reporting this problem.
