Re: [OE-core][scarthgap 19/55] python3-urllib3: Fix CVE-2026-97689

[Paul Barker <paul@pbarker.dev>]

On Mon, 2026-11-02 at 13:44 +0100, Yoann Congal wrote:
> On Mon Nov 2, 2026 at 12:02 PM CET, Paul Barker wrote:
> > On Sat, 2026-10-31 at 01:14 +0100, Yoann Congal wrote:
> > > From: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
> > > 
> > > Backport the upstream fix [1] as mentioned in [2]
> > > 
> > > [1] https://github.com/urllib3/urllib3/commit/cd770b059b543be29298ea5c52afb0b1b090f5ed
> > > [2] https://nvd.nist.gov/vuln/detail/cve-2026-97689
> > > 
> > > Testing:
> > >   - test_response.py::test_chunk_size_line_too_long - passed
> > >   - test_response.py::test_chunk_trailer_line_length (6 cases) - passed
> > >   - test_socketlevel.py::test_chunked_size_line_too_long_does_not_buffer - passed
> > >   - Full test_response.py: 161 passed, 45 skipped (no regressions)
> > > 
> > > Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
> > > Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
> > > ---
> > >  .../python3-urllib3/CVE-2026-97689.patch      | 251 ++++++++++++++++++
> > >  .../python/python3-urllib3_2.2.2.bb           |  14 +-
> > >  2 files changed, 258 insertions(+), 7 deletions(-)
> > >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2026-97689.patch
> > > 
> > > diff --git a/meta/recipes-devtools/python/python3-urllib3/CVE-2026-97689.patch b/meta/recipes-devtools/python/python3-urllib3/CVE-2026-97689.patch
> > > new file mode 100644
> > > index 00000000000..98b007324cf
> > > --- /dev/null
> > > +++ b/meta/recipes-devtools/python/python3-urllib3/CVE-2026-97689.patch
> > > @@ -0,0 +1,251 @@
> > > +From 5d5fac45ff18a8159c5a4aa973ed9fc2f5dd35ad Mon Sep 17 00:00:00 2001
> > > +From: Quentin Pradet <quentin.pradet@gmail.com>
> > > +Date: Tue, 15 Sep 2026 22:33:41 +0400
> > > +Subject: [PATCH] Merge commit from fork
> > > +
> > > +* Bound chunk-size line reads to prevent memory exhaustion DoS
> > > +
> > > +The streaming chunked path (HTTPResponse.stream() / read_chunked()) read
> > > +each chunk-size line with an unbounded readline(), unlike the plain read()
> > > +path which delegates to http.client's _MAXLINE-capped reader. A malicious
> > > +server could advertise Transfer-Encoding: chunked and then send a very long
> > > +run of bytes with no newline, forcing the client to buffer the entire run
> > > +before the chunk size could be rejected.
> > > +
> > > +This caps the chunk-size line (and the trailing CRLF line) at _MAXLINE,
> > > +raising ProtocolError when exceeded, matching the behaviour read() already
> > > +had. Only the size line is bounded; chunk bodies still go through the sized
> > > +_safe_read(), so legitimate large chunks are unaffected.
> > > +
> > > +Verified with a local malicious server streaming a 200 MiB unterminated
> > > +size line: stream() previously grew RSS by ~530 MB, now stays at ~1 MB and
> > > +fails fast, matching read(). A 5 MiB chunk body still streams correctly.
> > > +
> > > +* Fix a black formatting issue
> > > +
> > > +* Test chunked response trailer length limits
> > > +
> > > +* Fix number in the changelog entry
> > > +
> > > +---------
> > > +
> > > +Co-authored-by: Illia Volochii <illia.volochii@gmail.com>
> > > +
> > > +CVE: CVE-2026-97689
> > > +Upstream-Status: Backport [https://github.com/urllib3/urllib3/commit/cd770b059b543be29298ea5c52afb0b1b090f5ed]
> > > +
> > > +Note:
> > > + - changeLog change is not backported
> > > + - Adjusted commit change as per current version
> > 
> > Do we need more detail on the adjustments made during backporting?
> 
> I did not need more infos for this one, changes were obvious enough. And
> the resulting code is the same as upstream's.

Ok, sounds good. Thanks for confirming!

Best regards,

-- 
Paul Barker