From 052b0e9e1940acc9f2bc0bc82884d8dfc02c9b7e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lubo=C5=A1=20Uhliarik?= Date: Wed, 26 Mar 2025 07:11:52 +0100 Subject: [PATCH] Resolves: RHEL-57030 - squid aborts trying to access memory --- squid-5.5-fatal-read-data-from-mem.patch | 48 ++++++++++++++++++++++++ squid.spec | 9 ++++- 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 squid-5.5-fatal-read-data-from-mem.patch diff --git a/squid-5.5-fatal-read-data-from-mem.patch b/squid-5.5-fatal-read-data-from-mem.patch new file mode 100644 index 0000000..7960e6e --- /dev/null +++ b/squid-5.5-fatal-read-data-from-mem.patch @@ -0,0 +1,48 @@ +From 6c29ec591b1c777fc9a66f810f0ce5bc5076bc40 Mon Sep 17 00:00:00 2001 +From: Alex Rousskov +Date: Tue, 14 Nov 2023 18:40:37 +0000 +Subject: [PATCH] Bug 5317: FATAL attempt to read data from memory (#1579) + + FATAL: Squid has attempted to read data ... that is not present. + +Recent commit 122a6e3 attempted to deliver in-memory response body bytes +to a Store-reading client that requested (at least) response headers. +That optimization relied on the old canReadFromMemory() logic, but that +logic results in false positives when the checked read offset falls into +a gap between stored headers and the first body byte of a Content-Range. +In that case, a false positive leads to a readFromMemory() call and a +FATAL mem_hdr::copy() error. + +This workaround disables the above optimization without fixing +canReadFromMemory(). We believe that a readFromMemory() call that comes +right after response headers are delivered to the Store-reading client +will not suffer from the same problem because the client will supply the +read offset of the first body byte, eliminating the false positive. +--- + src/store_client.cc | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/src/store_client.cc b/src/store_client.cc +index 13ead49..d8ae028 100644 +--- a/src/store_client.cc ++++ b/src/store_client.cc +@@ -415,8 +415,9 @@ store_client::doCopy(StoreEntry *anEntry) + return; // failure + } + +- // send any immediately available body bytes even if we also sendHttpHeaders +- if (canReadFromMemory()) { ++ // Send any immediately available body bytes unless we sendHttpHeaders. ++ // TODO: Send those body bytes when we sendHttpHeaders as well. ++ if (!sendHttpHeaders && canReadFromMemory()) { + readFromMemory(); + noteNews(); // will sendHttpHeaders (if needed) as well + flags.store_copying = false; +@@ -502,6 +503,7 @@ store_client::canReadFromMemory() const + { + const auto &mem = entry->mem(); + const auto memReadOffset = nextHttpReadOffset(); ++ // XXX: This (lo <= offset < end) logic does not support Content-Range gaps. + return mem.inmem_lo <= memReadOffset && memReadOffset < mem.endOffset() && + parsingBuffer->spaceSize(); + } diff --git a/squid.spec b/squid.spec index a971704..08a222a 100644 --- a/squid.spec +++ b/squid.spec @@ -2,7 +2,7 @@ Name: squid Version: 5.5 -Release: 18%{?dist} +Release: 19%{?dist} Summary: The Squid proxy caching server Epoch: 7 # See CREDITS for breakdown of non GPLv2+ code @@ -50,6 +50,8 @@ Patch209: squid-5.5-halfclosed.patch Patch210: squid-5.5-ipv6-crash.patch # https://issues.redhat.com/browse/RHEL-12356 Patch211: squid-5.5-large-upload-buffer-dies.patch +# https://issues.redhat.com/browse/RHEL-57030 +Patch212: squid-5.5-fatal-read-data-from-mem.patch # Security patches # https://bugzilla.redhat.com/show_bug.cgi?id=2100721 @@ -177,6 +179,8 @@ lookup program (dnsserver), a program for retrieving FTP data %patch515 -p1 -b .CVE-2024-23638 %patch516 -p1 -b .ignore-wsp-chunk-sz +# patch506 follow-up +%patch212 -p1 -b .fatal-read-data-from-mem # https://bugzilla.redhat.com/show_bug.cgi?id=1679526 # Patch in the vendor documentation and used different location for documentation @@ -403,6 +407,9 @@ fi %changelog +* Wed Mar 26 2025 Luboš Uhliarik - 7:5.5-19 +- Resolves: RHEL-57030 - squid aborts trying to access memory + * Mon Nov 18 2024 Luboš Uhliarik - 7:5.5-18 - Resolves: RHEL-67869 - Remove gopher mention from spec file