helium-3rd-party/meta-openembedded
1
0
Fork 0
mirror of git://git.openembedded.org/meta-openembedded synced 2026-04-02 02:49:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

postgresql: Update to 13.5

Browse Source 
This is a security and bugfix release. With this update, the backported
patches for CVE-2021-2314 and CVE-2021-23222 are no longer needed. Full
release notes are available at:
https://www.postgresql.org/docs/release/13.5/

Signed-off-by: Robert Joslyn <robert.joslyn@redrectangle.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This commit is contained in:
Robert Joslyn 2022-01-15 13:33:51 -08:00 committed by Armin Kuster
parent 9b20f34ca9
commit 6704d6d3d7
5 changed files with 8 additions and 255 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
meta-oe/recipes-dbs/postgresql/files/0001-Add-support-for-RISC-V.patch
View File

@ -1,4 +1,4 @@
From b06a228a5fd1589fc9bed654b3288b321fc21aa1 Mon Sep 17 00:00:00 2001
From 0b60fe3c39b2f62f9867d955da82d9d20c42d028 Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" <rjones@redhat.com>
Date: Sun, 20 Nov 2016 15:04:52 +0000
Subject: [PATCH] Add support for RISC-V.
@ -9,9 +9,11 @@ extending the existing aarch64 macro works.
src/include/storage/s_lock.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index 6b368a5..f7d3387 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -316,11 +316,12 @@ tas(volatile slock_t *lock)
@@ -317,11 +317,12 @@ tas(volatile slock_t *lock)
/*
* On ARM and ARM64, we use __sync_lock_test_and_set(int *, int) if available.
@ -25,7 +27,7 @@ extending the existing aarch64 macro works.
#ifdef HAVE_GCC__SYNC_INT32_TAS
#define HAS_TEST_AND_SET
@@ -337,7 +338,7 @@ tas(volatile slock_t *lock)
@@ -338,7 +339,7 @@ tas(volatile slock_t *lock)
#define S_UNLOCK(lock) __sync_lock_release(lock)
#endif /* HAVE_GCC__SYNC_INT32_TAS */
@ -33,4 +35,4 @@ extending the existing aarch64 macro works.
+#endif /* __arm__ || __arm || __aarch64__ || __aarch64 || __riscv */
/* S/390 and S/390x Linux (32- and 64-bit zSeries) */
/*

2
meta-oe/recipes-dbs/postgresql/files/0001-configure.in-bypass-autoconf-2.69-version-check.patch
View File

@ -18,7 +18,7 @@ index fb14dcc..a2b4a4f 100644
+++ b/configure.in
@@ -19,10 +19,6 @@ m4_pattern_forbid(^PGAC_)dnl to catch undefined macros
AC_INIT([PostgreSQL], [13.4], [pgsql-bugs@lists.postgresql.org], [], [https://www.postgresql.org/])
AC_INIT([PostgreSQL], [13.5], [pgsql-bugs@lists.postgresql.org], [], [https://www.postgresql.org/])
-m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required.
-Untested combinations of 'autoconf' and PostgreSQL versions are not

116
meta-oe/recipes-dbs/postgresql/files/CVE-2021-23214.patch
View File

@ -1,116 +0,0 @@
From 24c2b9e42edb6d2f4ef2cead3b0aa1d6196adfce Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 8 Nov 2021 11:01:43 -0500
Subject: [PATCH 2/2] Reject extraneous data after SSL or GSS encryption
handshake.
The server collects up to a bufferload of data whenever it reads data
from the client socket. When SSL or GSS encryption is requested
during startup, any additional data received with the initial
request message remained in the buffer, and would be treated as
already-decrypted data once the encryption handshake completed.
Thus, a man-in-the-middle with the ability to inject data into the
TCP connection could stuff some cleartext data into the start of
a supposedly encryption-protected database session.
This could be abused to send faked SQL commands to the server,
although that would only work if the server did not demand any
authentication data. (However, a server relying on SSL certificate
authentication might well not do so.)
To fix, throw a protocol-violation error if the internal buffer
is not empty after the encryption handshake.
Our thanks to Jacob Champion for reporting this problem.
Security: CVE-2021-23214
Upstream-Status: Backport[https://github.com/postgres/postgres/commit/28e24125541545483093819efae9bca603441951]
CVE: CVE-2021-23214
Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
src/backend/libpq/pqcomm.c | 11 +++++++++++
src/backend/postmaster/postmaster.c | 23 ++++++++++++++++++++++-
src/include/libpq/libpq.h | 1 +
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c
index ee2cd86..4dd1c02 100644
--- a/src/backend/libpq/pqcomm.c
+++ b/src/backend/libpq/pqcomm.c
@@ -1183,6 +1183,17 @@ pq_getstring(StringInfo s)
}
}
+/* -------------------------------
+ * pq_buffer_has_data - is any buffered data available to read?
+ *
+ * This will *not* attempt to read more data.
+ * --------------------------------
+ */
+bool
+pq_buffer_has_data(void)
+{
+ return (PqRecvPointer < PqRecvLength);
+}
/* --------------------------------
* pq_startmsgread - begin reading a message from the client.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 5775fc0..1fcc3f8 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -2049,6 +2049,17 @@ retry1:
return STATUS_ERROR;
#endif
+ /*
+ * At this point we should have no data already buffered. If we do,
+ * it was received before we performed the SSL handshake, so it wasn't
+ * encrypted and indeed may have been injected by a man-in-the-middle.
+ * We report this case to the client.
+ */
+ if (pq_buffer_has_data())
+ ereport(FATAL,
+ (errcode(ERRCODE_PROTOCOL_VIOLATION),
+ errmsg("received unencrypted data after SSL request"),
+ errdetail("This could be either a client-software bug or evidence of an attempted man-in-the-middle attack.")));
/*
* regular startup packet, cancel, etc packet should follow, but not
* another SSL negotiation request, and a GSS request should only
@@ -2080,7 +2091,17 @@ retry1:
if (GSSok == 'G' && secure_open_gssapi(port) == -1)
return STATUS_ERROR;
#endif
-
+ /*
+ * At this point we should have no data already buffered. If we do,
+ * it was received before we performed the GSS handshake, so it wasn't
+ * encrypted and indeed may have been injected by a man-in-the-middle.
+ * We report this case to the client.
+ */
+ if (pq_buffer_has_data())
+ ereport(FATAL,
+ (errcode(ERRCODE_PROTOCOL_VIOLATION),
+ errmsg("received unencrypted data after GSSAPI encryption request"),
+ errdetail("This could be either a client-software bug or evidence of an attempted man-in-the-middle attack.")));
/*
* regular startup packet, cancel, etc packet should follow, but not
* another GSS negotiation request, and an SSL request should only
diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h
index b115247..9969692 100644
--- a/src/include/libpq/libpq.h
+++ b/src/include/libpq/libpq.h
@@ -73,6 +73,7 @@ extern int pq_getbyte(void);
extern int pq_peekbyte(void);
extern int pq_getbyte_if_available(unsigned char *c);
extern int pq_putbytes(const char *s, size_t len);
+extern bool pq_buffer_has_data(void);
/*
* prototypes for functions in be-secure.c
--
2.17.1

131
meta-oe/recipes-dbs/postgresql/files/CVE-2021-23222.patch
View File

@ -1,131 +0,0 @@
From 79125ead2a6a234086844bb42f06d49603fe6ca0 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 8 Nov 2021 11:14:56 -0500
Subject: [PATCH 1/2] libpq: reject extraneous data after SSL or GSS encryption
handshake.
libpq collects up to a bufferload of data whenever it reads data from
the socket. When SSL or GSS encryption is requested during startup,
any additional data received with the server's yes-or-no reply
remained in the buffer, and would be treated as already-decrypted data
once the encryption handshake completed. Thus, a man-in-the-middle
with the ability to inject data into the TCP connection could stuff
some cleartext data into the start of a supposedly encryption-protected
database session.
This could probably be abused to inject faked responses to the
client's first few queries, although other details of libpq's behavior
make that harder than it sounds. A different line of attack is to
exfiltrate the client's password, or other sensitive data that might
be sent early in the session. That has been shown to be possible with
a server vulnerable to CVE-2021-23214.
To fix, throw a protocol-violation error if the internal buffer
is not empty after the encryption handshake.
Our thanks to Jacob Champion for reporting this problem.
Security: CVE-2021-23222
Upstream-Status: Backport[https://github.com/postgres/postgres/commit/160c0258802d10b0600d7671b1bbea55d8e17d45]
CVE: CVE-2021-23222
Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
doc/src/sgml/protocol.sgml | 28 ++++++++++++++++++++++++++++
src/interfaces/libpq/fe-connect.c | 26 ++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index e26619e1b5..b692648fca 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1471,6 +1471,20 @@ SELCT 1/0;<!-- this typo is intentional -->
and proceed without requesting <acronym>SSL</acronym>.
</para>
+ <para>
+ When <acronym>SSL</acronym> encryption can be performed, the server
+ is expected to send only the single <literal>S</literal> byte and then
+ wait for the frontend to initiate an <acronym>SSL</acronym> handshake.
+ If additional bytes are available to read at this point, it likely
+ means that a man-in-the-middle is attempting to perform a
+ buffer-stuffing attack
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
+ Frontends should be coded either to read exactly one byte from the
+ socket before turning the socket over to their SSL library, or to
+ treat it as a protocol violation if they find they have read additional
+ bytes.
+ </para>
+
<para>
An initial SSLRequest can also be used in a connection that is being
opened to send a CancelRequest message.
@@ -1532,6 +1546,20 @@ SELCT 1/0;<!-- this typo is intentional -->
encryption.
</para>
+ <para>
+ When <acronym>GSSAPI</acronym> encryption can be performed, the server
+ is expected to send only the single <literal>G</literal> byte and then
+ wait for the frontend to initiate a <acronym>GSSAPI</acronym> handshake.
+ If additional bytes are available to read at this point, it likely
+ means that a man-in-the-middle is attempting to perform a
+ buffer-stuffing attack
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
+ Frontends should be coded either to read exactly one byte from the
+ socket before turning the socket over to their GSSAPI library, or to
+ treat it as a protocol violation if they find they have read additional
+ bytes.
+ </para>
+
<para>
An initial GSSENCRequest can also be used in a connection that is being
opened to send a CancelRequest message.
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index f80f4e98d8..57aee95183 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -3076,6 +3076,19 @@ keep_going: /* We will come back to here until there is
pollres = pqsecure_open_client(conn);
if (pollres == PGRES_POLLING_OK)
{
+ /*
+ * At this point we should have no data already buffered.
+ * If we do, it was received before we performed the SSL
+ * handshake, so it wasn't encrypted and indeed may have
+ * been injected by a man-in-the-middle.
+ */
+ if (conn->inCursor != conn->inEnd)
+ {
+ appendPQExpBufferStr(&conn->errorMessage,
+ libpq_gettext("received unencrypted data after SSL response\n"));
+ goto error_return;
+ }
+
/* SSL handshake done, ready to send startup packet */
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
@@ -3175,6 +3188,19 @@ keep_going: /* We will come back to here until there is
pollres = pqsecure_open_gss(conn);
if (pollres == PGRES_POLLING_OK)
{
+ /*
+ * At this point we should have no data already buffered.
+ * If we do, it was received before we performed the GSS
+ * handshake, so it wasn't encrypted and indeed may have
+ * been injected by a man-in-the-middle.
+ */
+ if (conn->inCursor != conn->inEnd)
+ {
+ appendPQExpBufferStr(&conn->errorMessage,
+ libpq_gettext("received unencrypted data after GSSAPI encryption response\n"));
+ goto error_return;
+ }
+
/* All set for startup packet */
conn->status = CONNECTION_MADE;
return PGRES_POLLING_WRITING;
--
2.17.1

4
meta-oe/recipes-dbs/postgresql/postgresql_13.4.bb → meta-oe/recipes-dbs/postgresql/postgresql_13.5.bb
View File

@ -7,8 +7,6 @@ SRC_URI += "\
file://0001-Add-support-for-RISC-V.patch \
file://0001-Improve-reproducibility.patch \
file://0001-configure.in-bypass-autoconf-2.69-version-check.patch \
file://CVE-2021-23214.patch \
file://CVE-2021-23222.patch \
"
SRC_URI[sha256sum] = "ea93e10390245f1ce461a54eb5f99a48d8cabd3a08ce4d652ec2169a357bc0cd"
SRC_URI[sha256sum] = "9b81067a55edbaabc418aacef457dd8477642827499560b00615a6ea6c13f6b3"