1 files changed, 116 insertions, 0 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
new file mode 100644
index 000000000..58bf81062
--- /dev/null
+++ b/meta-oe/recipes-dbs/postgresql/files/CVE-2021-23214.patch
@@ -0,0 +1,116 @@
+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
+