From f764a5f6dda453173d8e41b5fffda7e4fac9576a Mon Sep 17 00:00:00 2001
From: Andrew McDermott <amcdermo@redhat.com>
Date: Wed, 3 May 2023 14:35:32 +0100
Subject: Bump to 2.6.13

- Carry fix for https://github.com/haproxy/haproxy/issues/2114
- Resolves https://issues.redhat.com/browse/OCPBUGS-13232
- Remove ROADMAP file from haproxy.spec; the file was removed in haproxy-2.6.0
- Delete existing patches that are not required by 2.6.13
---
 .gitignore                                    |   1 +
 ...p-properly-reject-empty-http-header-.patch | 166 ------------------
 ...2-Refuse-interim-responses-with-end-.patch |  55 ------
 ...ays-remove-late-updates-when-freeing.patch |  37 ++++
 haproxy.spec                                  |  24 +--
 sources                                       |   2 +-
 6 files changed, 52 insertions(+), 233 deletions(-)
 delete mode 100644 0001-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch
 delete mode 100644 0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch
 create mode 100644 0001-BUG-MINOR-fd-always-remove-late-updates-when-freeing.patch

diff --git a/.gitignore b/.gitignore
index 9da8ca0..08cc425 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@
 /haproxy-2.2.24.tar.gz
 /haproxy-2.6.6.tar.gz
 /haproxy-2.6.9.tar.gz
+/haproxy-2.6.13.tar.gz
diff --git a/0001-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch b/0001-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch
deleted file mode 100644
index cfa96ff..0000000
--- a/0001-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch
+++ /dev/null
@@ -1,166 +0,0 @@
-From 718d3024329baa73d4c8528b12696de0df56f902 Mon Sep 17 00:00:00 2001
-From: Willy Tarreau <w@1wt.eu>
-Date: Thu, 9 Feb 2023 21:36:54 +0100
-Subject: [PATCH] BUG/CRITICAL: http: properly reject empty http header field
- names
-
-The HTTP header parsers surprizingly accepts empty header field names,
-and this is a leftover from the original code that was agnostic to this.
-
-When muxes were introduced, for H2 first, the HPACK decompressor needed
-to feed headers lists, and since empty header names were strictly
-forbidden by the protocol, the lists of headers were purposely designed
-to be terminated by an empty header field name (a principle that is
-similar to H1's empty line termination). This principle was preserved
-and generalized to other protocols migrated to muxes (H1/FCGI/H3 etc)
-without anyone ever noticing that the H1 parser was still able to deliver
-empty header field names to this list. In addition to this it turns out
-that the HPACK decompressor, despite a comment in the code, may
-successfully decompress an empty header field name, and this mistake
-was propagated to the QPACK decompressor as well.
-
-The impact is that an empty header field name may be used to truncate
-the list of headers and thus make some headers disappear. While for
-H2/H3 the impact is limited as haproxy sees a request with missing
-headers, and headers are not used to delimit messages, in the case of
-HTTP/1, the impact is significant because the presence (and sometimes
-contents) of certain sensitive headers is detected during the parsing.
-Thus, some of these headers may be seen, marked as present, their value
-extracted, but never delivered to upper layers and obviously not
-forwarded to the other side either. This can have for consequence that
-certain important header fields such as Connection, Upgrade, Host,
-Content-length, Transfer-Encoding etc are possibly seen as different
-between what haproxy uses to parse/forward/route and what is observed
-in http-request rules and of course, forwarded. One direct consequence
-is that it is possible to exploit this property in HTTP/1 to make
-affected versions of haproxy forward more data than is advertised on
-the other side, and bypass some access controls or routing rules by
-crafting extraneous requests.  Note, however, that responses to such
-requests will normally not be passed back to the client, but this can
-still cause some harm.
-
-This specific risk can be mostly worked around in configuration using
-the following rule that will rely on the bug's impact to precisely
-detect the inconsistency between the known body size and the one
-expected to be advertised to the server (the rule works from 2.0 to
-2.8-dev):
-
-  http-request deny if { fc_http_major 1 } !{ req.body_size 0 } !{ req.hdr(content-length) -m found } !{ req.hdr(transfer-encoding) -m found } !{ method CONNECT }
-
-This will exclusively block such carefully crafted requests delivered
-over HTTP/1. HTTP/2 and HTTP/3 do not need content-length, and a body
-that arrives without being announced with a content-length will be
-forwarded using transfer-encoding, hence will not cause discrepancies.
-In HAProxy 2.0 in legacy mode ("no option http-use-htx"), this rule will
-simply have no effect but will not cause trouble either.
-
-A clean solution would consist in modifying the loops iterating over
-these headers lists to check the header name's pointer instead of its
-length (since both are zero at the end of the list), but this requires
-to touch tens of places and it's very easy to miss one. Functions such
-as htx_add_header(), htx_add_trailer(), htx_add_all_headers() would be
-good starting points for such a possible future change.
-
-Instead the current fix focuses on blocking empty headers where they
-are first inserted, hence in the H1/HPACK/QPACK decoders. One benefit
-of the current solution (for H1) is that it allows "show errors" to
-report a precise diagnostic when facing such invalid HTTP/1 requests,
-with the exact location of the problem and the originating address:
-
-  $ printf "GET / HTTP/1.1\r\nHost: localhost\r\n:empty header\r\n\r\n" | nc 0 8001
-  HTTP/1.1 400 Bad request
-  Content-length: 90
-  Cache-Control: no-cache
-  Connection: close
-  Content-Type: text/html
-
-  <html><body><h1>400 Bad request</h1>
-  Your browser sent an invalid request.
-  </body></html>
-
-  $ socat /var/run/haproxy.stat <<< "show errors"
-  Total events captured on [10/Feb/2023:16:29:37.530] : 1
-
-  [10/Feb/2023:16:29:34.155] frontend decrypt (#2): invalid request
-    backend <NONE> (#-1), server <NONE> (#-1), event #0, src 127.0.0.1:31092
-    buffer starts at 0 (including 0 out), 16334 free,
-    len 50, wraps at 16336, error at position 33
-    H1 connection flags 0x00000000, H1 stream flags 0x00000810
-    H1 msg state MSG_HDR_NAME(17), H1 msg flags 0x00001410
-    H1 chunk len 0 bytes, H1 body len 0 bytes :
-
-    00000  GET / HTTP/1.1\r\n
-    00016  Host: localhost\r\n
-    00033  :empty header\r\n
-    00048  \r\n
-
-I want to address sincere and warm thanks for their great work to the
-team composed of the following security researchers who found the issue
-together and reported it: Bahruz Jabiyev, Anthony Gavazzi, and Engin
-Kirda from Northeastern University, Kaan Onarlioglu from Akamai
-Technologies, Adi Peleg and Harvey Tuch from Google. And kudos to Amaury
-Denoyelle from HAProxy Technologies for spotting that the HPACK and
-QPACK decoders would let this pass despite the comment explicitly
-saying otherwise.
-
-This fix must be backported as far as 2.0. The QPACK changes can be
-dropped before 2.6. In 2.0 there is also the equivalent code for legacy
-mode, which doesn't suffer from the list truncation, but it would better
-be fixed regardless.
-
-CVE-2023-25725 was assigned to this issue.
-
-(cherry picked from commit a8598a2eb11b6c989e81f0dbf10be361782e8d32)
-Signed-off-by: Willy Tarreau <w@1wt.eu>
-(cherry picked from commit a0e561ad7f29ed50c473f5a9da664267b60d1112)
-Signed-off-by: Willy Tarreau <w@1wt.eu>
-(cherry picked from commit 73be199c4f5f1ed468161a4c5e10ca77cd5989d8)
-[wt: dropped QPACK changes for 2.5]
-Signed-off-by: Willy Tarreau <w@1wt.eu>
-(cherry picked from commit f8b2b88aeae15dc3b261cd3749277ae75caf9db8)
-Signed-off-by: Willy Tarreau <w@1wt.eu>
-(cherry picked from commit 486cd730485c8a119ef65b3f792134b56e7941b4)
-Signed-off-by: Willy Tarreau <w@1wt.eu>
----
- src/h1.c        | 4 ++++
- src/hpack-dec.c | 9 +++++++++
- 2 files changed, 13 insertions(+)
-
-diff --git a/src/h1.c b/src/h1.c
-index bb8acfb34..83912343d 100644
---- a/src/h1.c
-+++ b/src/h1.c
-@@ -669,6 +669,10 @@ int h1_headers_to_hdr_list(char *start, const char *stop,
- 
- 		if (likely(*ptr == ':')) {
- 			col = ptr - start;
-+			if (col <= sol) {
-+				state = H1_MSG_HDR_NAME;
-+				goto http_msg_invalid;
-+			}
- 			EAT_AND_JUMP_OR_RETURN(ptr, end, http_msg_hdr_l1_sp, http_msg_ood, state, H1_MSG_HDR_L1_SP);
- 		}
- 
-diff --git a/src/hpack-dec.c b/src/hpack-dec.c
-index debd6119d..994986756 100644
---- a/src/hpack-dec.c
-+++ b/src/hpack-dec.c
-@@ -419,6 +419,15 @@ int hpack_decode_frame(struct hpack_dht *dht, const uint8_t *raw, uint32_t len,
- 			/* <name> and <value> are correctly filled here */
- 		}
- 
-+		/* We must not accept empty header names (forbidden by the spec and used
-+		 * as a list termination).
-+		 */
-+		if (!name.len) {
-+			hpack_debug_printf("##ERR@%d##\n", __LINE__);
-+			ret = -HPACK_ERR_INVALID_ARGUMENT;
-+			goto leave;
-+		}
-+
- 		/* here's what we have here :
- 		 *   - name.len > 0
- 		 *   - value is filled with either const data or data allocated from tmp
--- 
-2.38.3
-
diff --git a/0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch b/0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch
deleted file mode 100644
index 21d4404..0000000
--- a/0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 695ae6a7de3b178dc2891aa7957684a9890ffd63 Mon Sep 17 00:00:00 2001
-From: Christopher Faulet <cfaulet@haproxy.com>
-Date: Thu, 22 Dec 2022 09:47:01 +0100
-Subject: [PATCH] BUG/MEDIUM: mux-h2: Refuse interim responses with end-stream
- flag set
-
-As state in RFC9113#8.1, HEADERS frame with the ES flag set that carries an
-informational status code is malformed. However, there is no test on this
-condition.
-
-On 2.4 and higher, it is hard to predict consequences of this bug because
-end of the message is only reported with a flag. But on 2.2 and lower, it
-leads to a crash because there is an unexpected extra EOM block at the end
-of an interim response.
-
-Now, when a ES flag is detected on a HEADERS frame for an interim message, a
-stream error is sent (RST_STREAM/PROTOCOL_ERROR).
-
-This patch should solve the issue #1972. It should be backported as far as
-2.0.
-
-(cherry picked from commit 827a6299e6995c5c3ba620d8b7cbacdaef67f2c4)
-Signed-off-by: Willy Tarreau <w@1wt.eu>
-(cherry picked from commit ebfae006c6b5de1d1fe0cdd51847ec1e39d5cf59)
-Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
-(cherry picked from commit 84f5cba24f59b1c8339bb38323fcb01f434ba8e5)
-Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
-(cherry picked from commit f5748a98c34bc889cae9386ca4f7073ab3f4c6b1)
-Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
-(cherry picked from commit 2c681c6f30fb90adab4701e287ff7a7db669b2e7)
-[cf: ctx adjustment]
-Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
----
- src/mux_h2.c | 5 +++++
- 1 file changed, 5 insertions(+)
-
-diff --git a/src/mux_h2.c b/src/mux_h2.c
-index f9366b930..b18dd9b07 100644
---- a/src/mux_h2.c
-+++ b/src/mux_h2.c
-@@ -4591,6 +4591,11 @@ static int h2c_decode_headers(struct h2c *h2c, struct buffer *rxbuf, uint32_t *f
- 		*flags |= H2_SF_HEADERS_RCVD;
- 
- 	if ((h2c->dff & H2_F_HEADERS_END_STREAM)) {
-+		if (msgf & H2_MSGF_RSP_1XX) {
-+			/* RFC9113#8.1 : HEADERS frame with the ES flag set that carries an informational status code is malformed */
-+			TRACE_STATE("invalid interim response with ES flag!", H2_EV_RX_FRAME|H2_EV_RX_HDR|H2_EV_H2C_ERR|H2_EV_PROTO_ERR, h2c->conn);
-+			goto fail;
-+		}
- 		/* Mark the end of message using EOM */
- 		htx->flags |= HTX_FL_EOI; /* no more data are expected. Only EOM remains to add now */
- 		if (!htx_add_endof(htx, HTX_BLK_EOM)) {
--- 
-2.38.1
-
diff --git a/0001-BUG-MINOR-fd-always-remove-late-updates-when-freeing.patch b/0001-BUG-MINOR-fd-always-remove-late-updates-when-freeing.patch
new file mode 100644
index 0000000..28577ea
--- /dev/null
+++ b/0001-BUG-MINOR-fd-always-remove-late-updates-when-freeing.patch
@@ -0,0 +1,37 @@
+From 2b0aafdc92f691bc4b987300c9001a7cc3fb8d08 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Tue, 26 Jul 2022 19:06:17 +0200
+Subject: BUG/MINOR: fd: always remove late updates when freeing fd_updt[]
+
+Christopher found that since commit 8e2c0fa8e ("MINOR: fd: delete unused
+updates on close()") we may crash in a late stop due to an fd_delete()
+in the main thread performed after all threads have deleted the fd_updt[]
+array. Prior to that commit that didn't happen because we didn't touch
+the updates on this path, but now it may happen. We don't care about these
+ones anyway since the poller is stopped, so let's just wipe them by
+resetting their counter before freeing the array.
+
+No backport is needed as this is only 2.7.
+
+(cherry picked from commit b9831458374ba4bdba52aebe77a4005dcf59636d)
+[cf: Must be backported to 2.5]
+Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
+---
+ src/fd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/fd.c b/src/fd.c
+index 498dd565f..c005734df 100644
+--- a/src/fd.c
++++ b/src/fd.c
+@@ -1013,6 +1013,7 @@ static void deinit_pollers_per_thread()
+ /* Release the pollers per thread, to be called late */
+ static void free_pollers_per_thread()
+ {
++	fd_nbupdt = 0;
+ 	ha_free(&fd_updt);
+ }
+ 
+-- 
+2.38.4
+
diff --git a/haproxy.spec b/haproxy.spec
index ab66dd0..54cd5e4 100644
--- a/haproxy.spec
+++ b/haproxy.spec
@@ -6,23 +6,20 @@
 
 %global _hardened_build 1
 
-%define real_name haproxy22
+%define real_name haproxy26
 
 Name:           haproxy
-Version:        2.2.24
-Release:        3.rhaos4.14%{?dist}
+Version:        2.6.13
+Release:        1.rhaos4.14%{?dist}
 Summary:        Do not ship, install or use this, use %{real_name} subpackage instead
 
 License:        GPLv2+
 
 URL:            http://www.haproxy.org/
-Source0:        http://www.haproxy.org/download/2.2/src/haproxy-%{version}.tar.gz
+Source0:        http://www.haproxy.org/download/2.6/src/haproxy-%{version}.tar.gz
 
-# https://issues.redhat.com/browse/OCPBUGS-3553
-Patch0:         0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch
-
-# https://issues.redhat.com/browse/OCPBUGS-7428 (CVE-2023-25725)
-Patch1:         0001-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch
+# https://issues.redhat.com/browse/OCPBUGS-13232
+Patch0:         0001-BUG-MINOR-fd-always-remove-late-updates-when-freeing.patch
 
 BuildRequires:  openssl-devel
 BuildRequires:  pcre-devel
@@ -55,7 +52,6 @@ availability environments. Indeed, it can:
 %prep
 %setup -q
 %patch0 -p1
-%patch1 -p1
 
 %build
 regparm_opts=
@@ -92,11 +88,17 @@ fi
 %files -n %{real_name}
 %defattr(-,root,root,-)
 %doc doc/* examples/
-%doc CHANGELOG LICENSE README ROADMAP VERSION
+%doc CHANGELOG LICENSE README VERSION
 %{_mandir}/man1/*
 %{_sbindir}/%{name}
 
 %changelog
+* Wed May 03 2023 Andrew McDermott <amcdermo@redhat.com> - 2.6.13-1.rhaos4.14
+- Carry fix for https://github.com/haproxy/haproxy/issues/2114
+- Resolves https://issues.redhat.com/browse/OCPBUGS-13232
+- Remove ROADMAP file from haproxy.spec; the file was removed in haproxy-2.6.0
+- Delete existing patches that are not required by 2.6.13
+
 * Tue Mar 21 2023 Grant Spence <gspence@redhat.com> - 2.2.24-3.rhaos4.14
 - Artificially bumping release version as ART Tooling does not allow version to
   regress between OCP releases
diff --git a/sources b/sources
index a98cd72..9d2b556 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (haproxy-2.2.24.tar.gz) = 021d065e53503248de122fdd9431786b9f375a5f87aca76f870e17e44c8c4001a778bfb4e430b28af781a3f175f3643a549e363e964210c717f212c5966e68d8
+SHA512 (haproxy-2.6.13.tar.gz) = 672b1c5cd373261865d03af1c5cc42d1f6ec672f08c8482185d17dca2bd7dbd1e83e65107bb0bf1eee33a7149d9d25cca3f2c90beeacb38ab2e3ab74e9bdc5ed
-- 
2.38.5

