From 10514147edfdad4e542471aa88c1fc5ee8c0e5dc Mon Sep 17 00:00:00 2001
From: importbot <releng@rockylinux.org>
Date: Tue, 4 Feb 2025 09:12:28 +0000
Subject: [PATCH] import haproxy-2.4.22-3.el9_5.1

---
 .haproxy.checksum                             |  2 +-
 ...ad-certificate-chain-from-file-issue.patch | 37 ++++++++
 ...etry-flags-to-avoid-cpu-usage-spikes.patch | 86 +++++++++++++++++++
 SPECS/haproxy.spec                            | 12 ++-
 4 files changed, 135 insertions(+), 2 deletions(-)
 create mode 100644 SOURCES/RHEL-72952-fix-unable-to-load-certificate-chain-from-file-issue.patch
 create mode 100644 SOURCES/RHEL-72955-always-clear-retry-flags-to-avoid-cpu-usage-spikes.patch

diff --git a/.haproxy.checksum b/.haproxy.checksum
index 169301e..50752eb 100644
--- a/.haproxy.checksum
+++ b/.haproxy.checksum
@@ -1 +1 @@
-c51eb23338554f4327c9d4bc0195d980381a5a996b79aa8bb20fa8ce79d9d3bc
+75e9b168ef312b2af12c534aa99c5d9e47a80aa4405e58901c1cc7a32bed48a1
diff --git a/SOURCES/RHEL-72952-fix-unable-to-load-certificate-chain-from-file-issue.patch b/SOURCES/RHEL-72952-fix-unable-to-load-certificate-chain-from-file-issue.patch
new file mode 100644
index 0000000..8abf62d
--- /dev/null
+++ b/SOURCES/RHEL-72952-fix-unable-to-load-certificate-chain-from-file-issue.patch
@@ -0,0 +1,37 @@
+From d03501c1bab66283f143ff8629db7d7f62d3f4ad Mon Sep 17 00:00:00 2001
+From: William Lallemand <wlallemand@haproxy.com>
+Date: Mon, 2 Dec 2024 12:07:29 +0100
+Subject: [PATCH] BUG/MINOR: ssl: can't load a separated key file with openssl
+ > 3.0
+
+ssl_sock_load_pem_into_ckch() tries to load a PrivateKey with
+PEM_read_bio_PrivateKey in the PEM file. However the key might be in
+another file, and this might fill the error queue. In previous version
+of OpenSSL it wasn't a problem because the error was a
+PEM_R_NO_START_LINE which was ignored after, but some new versions
+(3.0.13 from ubuntu or newer versions) emits another error
+(error:1E08010C:DECODER routines::unsupported).
+
+The problem is fixed by clearing the OpenSSL error stack after trying to
+load optionnal content (Private key or DH).
+
+This is a fix for version 2.4 only, version 2.6 does not have this
+problem because c76c3c4e59c8 ("MEDIUM: ssl: Replace all DH objects by
+EVP_PKEY on OpenSSLv3 (via HASSL_DH type)") added a ERR_clear_error()
+but it should have been a separated bugfix. Should fix issue #2791.
+---
+ src/ssl_ckch.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/ssl_ckch.c b/src/ssl_ckch.c
+index 3b0f72c65edb3..0b7fd7938ff2c 100644
+--- a/src/ssl_ckch.c
++++ b/src/ssl_ckch.c
+@@ -529,6 +529,7 @@ int ssl_sock_load_pem_into_ckch(const char *path, char *buf, struct cert_key_and
+ 	dh = PEM_read_bio_DHparams(in, NULL, NULL, NULL);
+ 	/* no need to return an error there, dh is not mandatory */
+ #endif
++	ERR_clear_error();
+ 
+ 	/* Seek back to beginning of file */
+ 	if (BIO_reset(in) == -1) {
diff --git a/SOURCES/RHEL-72955-always-clear-retry-flags-to-avoid-cpu-usage-spikes.patch b/SOURCES/RHEL-72955-always-clear-retry-flags-to-avoid-cpu-usage-spikes.patch
new file mode 100644
index 0000000..d12b62d
--- /dev/null
+++ b/SOURCES/RHEL-72955-always-clear-retry-flags-to-avoid-cpu-usage-spikes.patch
@@ -0,0 +1,86 @@
+From 06a0fb4102523a7b38b90983b11bb08d6d69aea1 Mon Sep 17 00:00:00 2001
+From: Olivier Houchard <cognet@ci0.org>
+Date: Sat, 27 Jan 2024 22:58:29 +0100
+Subject: [PATCH] BUG/MAJOR: ssl_sock: Always clear retry flags in read/write
+ functions
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+It has been found that under some rare error circumstances,
+SSL_do_handshake() could return with SSL_ERROR_WANT_READ without
+even trying to call the read function, causing permanent wakeups
+that prevent the process from sleeping.
+
+It was established that this only happens if the retry flags are
+not systematically cleared in both directions upon any I/O attempt,
+but, given the lack of documentation on this topic, it is hard to
+say if this rather strange behavior is expected or not, otherwise
+why wouldn't the library always clear the flags by itself before
+proceeding?
+
+In addition, this only seems to affect OpenSSL 1.1.0 and above,
+and does not affect wolfSSL nor aws-lc.
+
+A bisection on haproxy showed that this issue was first triggered by
+commit a8955d57ed ("MEDIUM: ssl: provide our own BIO."), which means
+that OpenSSL's socket BIO does not have this problem. And this one
+does always clear the flags before proceeding. So let's just proceed
+the same way. It was verified that it properly fixes the problem,
+does not affect other implementations, and doesn't cause any freeze
+nor spurious wakeups either.
+
+Many thanks to Valentín Gutiérrez for providing a network capture
+showing the incident as well as a reproducer. This is GH issue #2403.
+
+This patch needs to be backported to all versions that include the
+commit above, i.e. as far as 2.0.
+
+(cherry picked from commit 1ad19917213fac57ee37e581b0ef137e36c6309d)
+Signed-off-by: Willy Tarreau <w@1wt.eu>
+(cherry picked from commit bef2bc4cb6f4fa942d3659f25770cbfc137327b2)
+Signed-off-by: Willy Tarreau <w@1wt.eu>
+(cherry picked from commit a0b31bda308bccd987c15007a5384b602fcd7415)
+Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
+(cherry picked from commit 571f5ebb056f533a8dac0d9948d0a3cecaeeda26)
+Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
+(cherry picked from commit a067ce17f89b9b98ccc669521e0f859f5f62b3dd)
+Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
+(cherry picked from commit d292e56c7e70eff215dd37b3e9e53c36499de867)
+Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
+---
+ src/ssl_sock.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/ssl_sock.c b/src/ssl_sock.c
+index 9e7e7369d744..ef34fb61d1dd 100644
+--- a/src/ssl_sock.c
++++ b/src/ssl_sock.c
+@@ -158,11 +158,11 @@ static int ha_ssl_write(BIO *h, const char *buf, int num)
+ 	tmpbuf.data = num;
+ 	tmpbuf.head = 0;
+ 	ret = ctx->xprt->snd_buf(ctx->conn, ctx->xprt_ctx, &tmpbuf, num, 0);
++	BIO_clear_retry_flags(h);
+ 	if (ret == 0 && !(ctx->conn->flags & (CO_FL_ERROR | CO_FL_SOCK_WR_SH))) {
+ 		BIO_set_retry_write(h);
+ 		ret = -1;
+-	} else if (ret == 0)
+-		 BIO_clear_retry_flags(h);
++	}
+ 	return ret;
+ }
+ 
+@@ -190,11 +190,11 @@ static int ha_ssl_read(BIO *h, char *buf, int size)
+ 	tmpbuf.data = 0;
+ 	tmpbuf.head = 0;
+ 	ret = ctx->xprt->rcv_buf(ctx->conn, ctx->xprt_ctx, &tmpbuf, size, 0);
++	BIO_clear_retry_flags(h);
+ 	if (ret == 0 && !(ctx->conn->flags & (CO_FL_ERROR | CO_FL_SOCK_RD_SH))) {
+ 		BIO_set_retry_read(h);
+ 		ret = -1;
+-	} else if (ret == 0)
+-		BIO_clear_retry_flags(h);
++	}
+ 
+ 	return ret;
+ }
diff --git a/SPECS/haproxy.spec b/SPECS/haproxy.spec
index 09500d2..1aeddcd 100644
--- a/SPECS/haproxy.spec
+++ b/SPECS/haproxy.spec
@@ -8,7 +8,7 @@
 
 Name:           haproxy
 Version:        2.4.22
-Release:        3%{?dist}
+Release:        3%{?dist}.1
 Summary:        HAProxy reverse proxy for high availability environments
 
 License:        GPLv2+
@@ -29,6 +29,8 @@ Patch3: RHEL-18169_h2-reject-special-char-from-pseudo-path-header.patch
 Patch4: RHEL-18169_http-add-new-function-http_path_has_forbidden_char.patch
 Patch5: RHEL-18169_ist-add-new-function-ist_find_range.patch
 Patch6: RHEL-18169_regtest-add-accept-invalid-http-request.patch
+Patch7: RHEL-72955-always-clear-retry-flags-to-avoid-cpu-usage-spikes.patch
+Patch8: RHEL-72952-fix-unable-to-load-certificate-chain-from-file-issue.patch
 
 BuildRequires:  gcc
 BuildRequires:  lua-devel
@@ -65,6 +67,8 @@ availability environments. Indeed, it can:
 %patch -P4 -p1
 %patch -P5 -p1
 %patch -P6 -p1
+%patch -P7 -p1
+%patch -P8 -p1
 
 %build
 regparm_opts=
@@ -147,6 +151,12 @@ done
 %{_sysusersdir}/%{name}.conf
 
 %changelog
+* Tue Jan  7 2025 Oyvind Albrigtsen <oalbrigt@redhat.com> - 2.4.22-3.1
+- Always clear retry flags in read/write functions to avoid CPU
+  usage spikes
+- Fix "unable to load certificate chain from file" issue
+  Resolves: RHEL-72955, RHEL-72952
+
 * Tue Jan 23 2024 Ryan O'Hara <rohara@redhat.com> - 2.4.22-3
 - Reject "#" as part of URI path component (CVE-2023-45539, RHEL-18169)
 
-- 
GitLab