REDHAT-BUG-2543285: Buffer Overflow
A heap buffer overflow was found in libsoup's client-side WebSocket frame construction / masking path.
Outgoing frames are built in a GByteArray. For a send payload larger than the array can represent (at/above ~2^31), gbytearraysizednew() / append truncated the length while xorwithmask() still iterated the full attacker-/caller-controlled length, writing past the small allocation during masking.
Fixed by rejecting outgoing payloads above MAXOUTGOINGPAYLOADSIZE both before and after extensions process the payload (commit d7f074f8, libsoup 3.7.3).
References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 7) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d7f074f8
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 d7f074f8
Event History
Frequently Asked Questions
What conditions are required to trigger the overflow?
An application using libsoup as a WebSocket client must send an outgoing payload at or above approximately 2^31 bytes. The vulnerable path is the client-side frame construction and masking code, where the payload length is caller-controlled.
Can WebSocket extensions affect exposure?
Yes. The fix validates the payload size both before and after extensions process it, indicating that extension processing can affect the outgoing payload size that reaches frame construction.
What mitigation is available if upgrading is not immediately possible?
Prevent applications from sending WebSocket payloads near or above approximately 2^31 bytes. Enforce an outgoing WebSocket message-size limit before handing payloads to libsoup, including after any extension or transformation processing.
How can I determine whether a fix is present?
The issue is fixed in libsoup 3.7.3 by commit d7f074f8. A fixed build rejects outgoing payloads above MAX_OUTGOING_PAYLOAD_SIZE before and after extension processing.