REDHAT-BUG-2543224: Buffer Overflow
A heap buffer overflow condition was found in libsoup's soupuridecodedatauri().
After percent-decoding a data URI payload marked ;base64, the code called gbase64decodeinplace(), which measures input with strlen(). Percent-decoded content can contain embedded NUL bytes (for example data:;base64,A%00B), so the measured length was too short. gbase64decodeinplace() returned without writing a valid output length; the uninitialized length was then stored as the size of the returned GBytes, allowing callers to read past the allocation.
Fixed upstream by decoding with gbase64decodestep() using the real buffer length (commit e4f03226, libsoup 3.7.3).
References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 1) https://gitlab.gnome.org/GNOME/libsoup/-/commit/e4f03226
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libsoupto a version that resolves this vulnerability.Fixed in 3.7.3Patch e4f03226
Event History
Frequently Asked Questions
What input is needed to trigger the issue?
An attacker needs to supply a data URI whose payload is marked ;base64 and contains percent-encoded data that becomes an embedded NUL byte after decoding, such as data:;base64,A%00B. The embedded NUL causes the base64 decoder to measure a shorter length than the actual buffer.
What is the impact after triggering the overflow condition?
The invalid decoded-length value is stored as the size of the returned GBytes object. Callers may then read beyond the allocated buffer.
Which fix addresses this issue?
The upstream fix replaces the in-place base64 decoding path with g_base64_decode_step(), using the real buffer length. It is identified by upstream commit e4f03226 and is included in libsoup 3.7.3.