Univention Bugzilla – Bug 53270
postgresql-9.6: Multiple issues (4.4)
Last modified: 2021-05-19 18:01:11 CEST
New Debian postgresql-9.6 9.6.22-0+deb9u1 fixes: This update addresses the following issues: * 9.6.22-0+deb9u1 (Wed, 12 May 2021 16:53:28 +0200) * New upstream version. + 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) * 9.6.21-0+deb9u1 (Wed, 12 May 2021 16:53:28 +0200) + Fix CREATE INDEX CONCURRENTLY to wait for concurrent prepared transactions (Andrey Borodin) At the point where CREATE INDEX CONCURRENTLY waits for all concurrent transactions to complete so that it can see rows they inserted, it must also wait for all prepared transactions to complete, for the same reason. Its failure to do so meant that rows inserted by prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. In installations that have enabled prepared transactions (max_prepared_transactions > 0), it's recommended to reindex any concurrently-built indexes in case this problem occurred when they were built. * 9.6.22-0+deb9u1 (Wed, 12 May 2021 16:53:28 +0200) * New upstream version. + 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) * 9.6.21-0+deb9u1 (Wed, 12 May 2021 16:53:28 +0200) + Fix CREATE INDEX CONCURRENTLY to wait for concurrent prepared transactions (Andrey Borodin) At the point where CREATE INDEX CONCURRENTLY waits for all concurrent transactions to complete so that it can see rows they inserted, it must also wait for all prepared transactions to complete, for the same reason. Its failure to do so meant that rows inserted by prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. In installations that have enabled prepared transactions (max_prepared_transactions > 0), it's recommended to reindex any concurrently-built indexes in case this problem occurred when they were built.
--- mirror/ftp/4.4/unmaintained/4.4-8/source/postgresql-9.6_9.6.20-0+deb9u1.dsc +++ apt/ucs_4.4-0-errata4.4-8/source/postgresql-9.6_9.6.22-0+deb9u1.dsc @@ -1,3 +1,50 @@ +9.6.22-0+deb9u1 [Wed, 12 May 2021 16:53:28 +0200] Christoph Berg <myon@debian.org>: + + * New upstream version. + + + 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) + +9.6.21-0+deb9u1 [Wed, 12 May 2021 16:53:28 +0200] Christoph Berg <myon@debian.org>: + + * New upstream version. + + + Fix CREATE INDEX CONCURRENTLY to wait for concurrent prepared + transactions (Andrey Borodin) + + At the point where CREATE INDEX CONCURRENTLY waits for all concurrent + transactions to complete so that it can see rows they inserted, it must + also wait for all prepared transactions to complete, for the same + reason. Its failure to do so meant that rows inserted by prepared + transactions might be omitted from the new index, causing queries + relying on the index to miss such rows. In installations that have + enabled prepared transactions (max_prepared_transactions > 0), it's + recommended to reindex any concurrently-built indexes in case this + problem occurred when they were built. + 9.6.20-0+deb9u1 [Tue, 01 Dec 2020 12:11:51 +0100] Christoph Berg <myon@debian.org>: * New upstream version. <http://piuparts.knut.univention.de/4.4-8/#6505059383539000015>
OK: yaml OK: announce_errata OK: patch OK: piuparts [4.4-8] 4c8c778a70 Bug #53270: postgresql-9.6 9.6.22-0+deb9u1 doc/errata/staging/postgresql-9.6.yaml | 78 ++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+)
<https://errata.software-univention.de/#/?erratum=4.4x978>