mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-09-14 18:24:01 -09:00
5541178b12
Thanks to OpenEmbedded Community for providing the patches:
https://github.com/openembedded/meta-openembedded/blob/scarthgap/meta-python/recipes-devtools/python/python3-cbor2/
- CVE-2025-64076:
Multiple vulnerabilities exist in cbor2 through version 5.7.0 in the
decode_definite_long_string() function of the C extension decoder
(source/decoder.c): (1) Integer Underflow Leading to Out-of-Bounds
Read (CWE-191, CWE-125): An incorrect variable reference and missing
state reset in the chunk processing loop causes buffer_length to not
be reset to zero after UTF-8 character consumption. This results in
subsequent chunk_length calculations producing negative values (e.g.,
chunk_length = 65536 - buffer_length), which are passed as signed
integers to the read() method, potentially triggering unlimited read
operations and resource exhaustion. (2) Memory Leak via Missing
Reference Count Release (CWE-401): The main processing loop fails to
release Python object references (Py_DECREF) for chunk objects
allocated in each iteration. For CBOR strings longer than 65536 bytes,
this causes cumulative memory leaks proportional to the payload size,
enabling memory exhaustion attacks through repeated processing of
large CBOR payloads. Both vulnerabilities can be exploited remotely
without authentication by sending specially-crafted CBOR data
containing definite-length text strings with multi-byte UTF-8
characters positioned at 65536-byte chunk boundaries. Successful
exploitation results in denial of service through process crashes
(CBORDecodeEOF exceptions) or memory exhaustion. The vulnerabilities
affect all applications using cbor2's C extension to process untrusted
CBOR data, including web APIs, IoT data collectors, and message queue
processors. Fixed in commit 851473490281f82d82560b2368284ef33cf6e8f9
pushed with released version 5.7.1.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-64076
- CVE-2025-68131:
cbor2 provides encoding and decoding for the Concise Binary Object
Representation (CBOR) serialization format. Starting in version 3.0.0
and prior to version 5.8.0, whhen a CBORDecoder instance is reused
across multiple decode operations, values marked with the shareable
tag (28) persist in memory and can be accessed by subsequent CBOR
messages using the sharedref tag (29). This allows an attacker-
controlled message to read data from previously decoded messages if
the decoder is reused across trust boundaries. Version 5.8.0 patches
the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68131
- CVE-2026-26209:
cbor2 provides encoding and decoding for the Concise Binary Object
Representation (CBOR) serialization format. Versions prior to 5.9.0
are vulnerable to a Denial of Service (DoS) attack caused by
uncontrolled recursion when decoding deeply nested CBOR structures.
This vulnerability affects both the pure Python implementation and the
C extension `_cbor2`. The C extension relies on Python's internal
recursion limits `Py_EnterRecursiveCall` rather than a data-driven
depth limit, meaning it still raises `RecursionError` and crashes the
worker process when the limit is hit. While the library handles
moderate nesting levels, it lacks a hard depth limit. An attacker can
supply a crafted CBOR payload containing approximately 100,000 nested
arrays `0x81`. When `cbor2.loads()` attempts to parse this, it hits
the Python interpreter's maximum recursion depth or exhausts the
stack, causing the process to crash with a `RecursionError`. Because
the library does not enforce its own limits, it allows an external
attacker to exhaust the host application's stack resource. In many web
application servers (e.g., Gunicorn, Uvicorn) or task queues (Celery),
an unhandled `RecursionError` terminates the worker process
immediately. By sending a stream of these small (<100KB) malicious
packets, an attacker can repeatedly crash worker processes, resulting
in a complete Denial of Service for the application. Version 5.9.0
patches the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-26209
(cherry picked from commit b676a4f51b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
42 lines
1.5 KiB
Diff
42 lines
1.5 KiB
Diff
From 2349197bea8ebd1bf57a68f4a6549d8fd7585e66 Mon Sep 17 00:00:00 2001
|
|
From: Chenhao <24435007+tylzh97@users.noreply.github.com>
|
|
Date: Wed, 22 Oct 2025 20:39:31 +0800
|
|
Subject: [PATCH] Fix: bug in `decode_definite_long_string()` that causes
|
|
incorrect chunk length calculation (#265)
|
|
|
|
Upstream: https://github.com/agronholm/cbor2/commit/2349197bea8ebd1bf57a68f4a6549d8fd7585e66
|
|
CVE: CVE-2025-64076
|
|
[thomas: stripped tests and changelog]
|
|
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
|
|
---
|
|
source/decoder.c | 8 +++++++-
|
|
1 files changed, 7 insertions(+), 1 deletion(-)
|
|
|
|
diff --git a/source/decoder.c b/source/decoder.c
|
|
index 043210b3..8b6b842c 100644
|
|
--- a/source/decoder.c
|
|
+++ b/source/decoder.c
|
|
@@ -758,7 +758,7 @@ decode_definite_long_string(CBORDecoderObject *self, Py_ssize_t length)
|
|
char *buffer = NULL;
|
|
while (left) {
|
|
// Read up to 65536 bytes of data from the stream
|
|
- Py_ssize_t chunk_length = 65536 - buffer_size;
|
|
+ Py_ssize_t chunk_length = 65536 - buffer_length;
|
|
if (left < chunk_length)
|
|
chunk_length = left;
|
|
|
|
@@ -828,7 +828,13 @@ decode_definite_long_string(CBORDecoderObject *self, Py_ssize_t length)
|
|
memcpy(buffer, bytes_buffer + consumed, unconsumed);
|
|
}
|
|
buffer_length = unconsumed;
|
|
+ } else {
|
|
+ // All bytes consumed, reset buffer_length
|
|
+ buffer_length = 0;
|
|
}
|
|
+
|
|
+ Py_DECREF(chunk);
|
|
+ chunk = NULL;
|
|
}
|
|
|
|
if (ret && string_namespace_add(self, ret, length) == -1)
|