mirrors/meta-openembedded
1
0
Fork 0
mirror of https://github.com/openembedded/meta-openembedded.git synced 2026-06-14 17:59:59 +00:00
Code Issues Projects Releases Wiki Activity

python3-waitress: patch CVE-2024-49768

Browse Source 
Details: https://nvd.nist.gov/vuln/detail/CVE-2024-49768

Pick the patch mentioned in the NVD report (which is a merge commit,
and the patches here are the individual commits from that merge)

Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
This commit is contained in:
Gyorgy Sarvari
2026-01-07 10:27:46 +01:00
parent e330e3508d
commit 1ea440cd62
5 changed files with 350 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
meta-python/recipes-devtools/python/python3-waitress/CVE-2024-49768-3.patch
+60
View File
@@ -0,0 +1,60 @@
From 5cf72c7d9f60e96a3ca65e410098e11d8053749d Mon Sep 17 00:00:00 2001
From: Delta Regeer <bertjw@regeer.org>
Date: Sat, 26 Oct 2024 22:13:08 -0600
Subject: [PATCH] Fix a race condition on recv_bytes boundary when request is
invalid
A remote client may send a request that is exactly recv_bytes long,
followed by a secondary request using HTTP pipelining.
When request lookahead is disabled (default) we won't read any more
requests, and when the first request fails due to a parsing error, we
simply close the connection.
However when request lookahead is enabled, it is possible to process and
receive the first request, start sending the error message back to the
client while we read the next request and queue it. This will allow the
secondar request to be serviced by the worker thread while the
connection should be closed.
The fix here checks if we should not have read the data in the first
place (because the conection is going to be torn down) while we hold the
`requests_lock` which means the service thread can't be in the middle of
flipping the `close_when_flushed` flag.
CVE: CVE-2024-49768
Upstream-Status: Backport [https://github.com/Pylons/waitress/commit/f4ba1c260cf17156b582c6252496213ddc96b591]
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
---
src/waitress/channel.py | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/waitress/channel.py b/src/waitress/channel.py
index eb59dd3..756adce 100644
--- a/src/waitress/channel.py
+++ b/src/waitress/channel.py
@@ -147,7 +147,7 @@ class HTTPChannel(wasyncore.dispatcher):
# 1. We're not already about to close the connection.
# 2. We're not waiting to flush remaining data before closing the
# connection
- # 3. There are not too many tasks already queued
+ # 3. There are not too many tasks already queued (if lookahead is enabled)
# 4. There's no data in the output buffer that needs to be sent
# before we potentially create a new task.
@@ -203,6 +203,15 @@ class HTTPChannel(wasyncore.dispatcher):
return False
with self.requests_lock:
+ # Don't bother processing anymore data if this connection is about
+ # to close. This may happen if readable() returned True, on the
+ # main thread before the service thread set the close_when_flushed
+ # flag, and we read data but our service thread is attempting to
+ # shut down the connection due to an error. We want to make sure we
+ # do this while holding the request_lock so that we can't race
+ if self.will_close or self.close_when_flushed:
+ return False
+
while data:
if self.request is None:
self.request = self.parser_class(self.adj)