1 files changed, 0 insertions, 116 deletions

diff --git a/meta-oe/recipes-dbs/postgresql/files/CVE-2021-23214.patch b/meta-oe/recipes-dbs/postgresql/files/CVE-2021-23214.patch
deleted file mode 100644
index 58bf81062..000000000
--- a/meta-oe/recipes-dbs/postgresql/files/CVE-2021-23214.patch
+++ /dev/null
@@ -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
-