diff --git a/.gitignore b/.gitignore
index ec3a304..b3c4ea2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-SOURCES/haproxy-1.8.15.tar.gz
+SOURCES/haproxy-1.8.23.tar.gz
diff --git a/.haproxy.metadata b/.haproxy.metadata
index 8bda435..3d2a7e7 100644
--- a/.haproxy.metadata
+++ b/.haproxy.metadata
@@ -1 +1 @@
-ed7dfe5c7fc39fbb3b54e981eb709fd8bcd87042 SOURCES/haproxy-1.8.15.tar.gz
+c1b6c1d4d5de55bcad874a0a7a02a94db5638b1f SOURCES/haproxy-1.8.23.tar.gz
diff --git a/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch b/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch
deleted file mode 100644
index 24ed204..0000000
--- a/SOURCES/bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 4e372dc350be5c72b88546bf03392a5793cea179 Mon Sep 17 00:00:00 2001
-From: Willy Tarreau <w@1wt.eu>
-Date: Sun, 29 Mar 2020 08:53:31 +0200
-Subject: BUG/CRITICAL: hpack: never index a header into the headroom after
- wrapping
-
-The HPACK header table is implemented as a wrapping list inside a contigous
-area. Headers names and values are stored from right to left while indexes
-are stored from left to right. When there's no more room to store a new one,
-we wrap to the right again, or possibly defragment it if needed. The condition
-do use the right part (called tailroom) or the left part (called headroom)
-depends on the location of the last inserted header. After wrapping happens,
-the code forces to stick to tailroom by pretending there's no more headroom,
-so that the size fit test always fails. The problem is that nothing prevents
-from storing a header with an empty name and empty value, resulting in a
-total size of zero bytes, which satisfies the condition to use the headroom.
-Doing this in a wrapped buffer results in changing the "front" header index
-and causing miscalculations on the available size and the addresses of the
-next headers. This may even allow to overwrite some parts of the index,
-opening the possibility to perform arbitrary writes into a 32-bit relative
-address space.
-
-This patch fixes the issue by making sure the headroom is considered only
-when the buffer does not wrap, instead of relying on the zero size. This
-must be backported to all versions supporting H2, which is as far as 1.8.
-
-Many thanks to Felix Wilhelm of Google Project Zero for responsibly
-reporting this problem with a reproducer and a detailed analysis.
----
- src/hpack-tbl.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/src/hpack-tbl.c b/src/hpack-tbl.c
-index 70d7f35834..727ff7a17b 100644
---- a/src/hpack-tbl.c
-+++ b/src/hpack-tbl.c
-@@ -346,9 +346,9 @@ int hpack_dht_insert(struct hpack_dht *dht, struct ist name, struct ist value)
- * room left in the tail to suit the protocol, but tests show that in
- * practice it almost never happens in other situations so the extra
- * test is useless and we simply fill the headroom as long as it's
-- * available.
-+ * available and we don't wrap.
- */
-- if (headroom >= name.len + value.len) {
-+ if (prev == dht->front && headroom >= name.len + value.len) {
- /* install upfront and update ->front */
- dht->dte[head].addr = dht->dte[dht->front].addr - (name.len + value.len);
- dht->front = head;
---
-2.20.1
-
diff --git a/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch b/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch
new file mode 100644
index 0000000..24ed204
--- /dev/null
+++ b/SOURCES/bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch
@@ -0,0 +1,51 @@
+From 4e372dc350be5c72b88546bf03392a5793cea179 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Sun, 29 Mar 2020 08:53:31 +0200
+Subject: BUG/CRITICAL: hpack: never index a header into the headroom after
+ wrapping
+
+The HPACK header table is implemented as a wrapping list inside a contigous
+area. Headers names and values are stored from right to left while indexes
+are stored from left to right. When there's no more room to store a new one,
+we wrap to the right again, or possibly defragment it if needed. The condition
+do use the right part (called tailroom) or the left part (called headroom)
+depends on the location of the last inserted header. After wrapping happens,
+the code forces to stick to tailroom by pretending there's no more headroom,
+so that the size fit test always fails. The problem is that nothing prevents
+from storing a header with an empty name and empty value, resulting in a
+total size of zero bytes, which satisfies the condition to use the headroom.
+Doing this in a wrapped buffer results in changing the "front" header index
+and causing miscalculations on the available size and the addresses of the
+next headers. This may even allow to overwrite some parts of the index,
+opening the possibility to perform arbitrary writes into a 32-bit relative
+address space.
+
+This patch fixes the issue by making sure the headroom is considered only
+when the buffer does not wrap, instead of relying on the zero size. This
+must be backported to all versions supporting H2, which is as far as 1.8.
+
+Many thanks to Felix Wilhelm of Google Project Zero for responsibly
+reporting this problem with a reproducer and a detailed analysis.
+---
+ src/hpack-tbl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/hpack-tbl.c b/src/hpack-tbl.c
+index 70d7f35834..727ff7a17b 100644
+--- a/src/hpack-tbl.c
++++ b/src/hpack-tbl.c
+@@ -346,9 +346,9 @@ int hpack_dht_insert(struct hpack_dht *dht, struct ist name, struct ist value)
+ * room left in the tail to suit the protocol, but tests show that in
+ * practice it almost never happens in other situations so the extra
+ * test is useless and we simply fill the headroom as long as it's
+- * available.
++ * available and we don't wrap.
+ */
+- if (headroom >= name.len + value.len) {
++ if (prev == dht->front && headroom >= name.len + value.len) {
+ /* install upfront and update ->front */
+ dht->dte[head].addr = dht->dte[dht->front].addr - (name.len + value.len);
+ dht->front = head;
+--
+2.20.1
+
diff --git a/SOURCES/haproxy.service b/SOURCES/haproxy.service
index b32d00c..2b3a35e 100644
--- a/SOURCES/haproxy.service
+++ b/SOURCES/haproxy.service
@@ -8,6 +8,7 @@ ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q
ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE
ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q
ExecReload=/bin/kill -USR2 $MAINPID
+SuccessExitStatus=143
KillMode=mixed
Type=notify
diff --git a/SPECS/haproxy.spec b/SPECS/haproxy.spec
index c3efda6..fe10158 100644
--- a/SPECS/haproxy.spec
+++ b/SPECS/haproxy.spec
@@ -7,8 +7,8 @@
%global _hardened_build 1
Name: haproxy
-Version: 1.8.15
-Release: 6%{?dist}.1
+Version: 1.8.23
+Release: 3%{?dist}
Summary: HAProxy reverse proxy for high availability environments
Group: System Environment/Daemons
@@ -23,7 +23,7 @@ Source4: %{name}.sysconfig
Source5: halog.1
Patch0: bz1664533-fix-handling-priority-flag-HTTP2-decoder.patch
-Patch1: bz1819518-fix-handling-hpack-zero-bytes-overwrite.patch
+Patch1: bz1819519-fix-handling-hpack-zero-bytes-overwrite.patch
BuildRequires: lua-devel
BuildRequires: pcre-devel
@@ -140,8 +140,14 @@ exit 0
%{_mandir}/man1/*
%changelog
-* Wed Apr 01 2020 Ryan O'Hara <rohara@redhat.com> - 1.8.15-6.1
-- - Fix hapack zero byte input causing overwrite (CVE-2020-11100, #1819518)
+* Wed Apr 01 2020 Ryan O'Hara <rohara@redhat.com> - 1.8.23-3
+- Fix hapack zero byte input causing overwrite (CVE-2020-11100, #1819519)
+
+* Fri Dec 13 2019 Ryan O'Hara <rohara@redhat.com> - 1.8.23-2
+- Consider exist status 143 as success (#1778844)
+
+* Mon Dec 02 2019 Ryan O'Hara <rohara@redhat.com> - 1.8.23-1
+- Update to 1.8.23 (#1774745)
* Fri Jul 19 2019 Ryan O'Hara <rohara@redhat.com> - 1.8.15-6
- Add gating tests (#1682106)