VYPR
Unrated severityNVD Advisory· Published Dec 30, 2025· Updated Apr 15, 2026

CVE-2022-50838

CVE-2022-50838

Description

In the Linux kernel, the following vulnerability has been resolved:

net: stream: purge sk_error_queue in sk_stream_kill_queues()

Changheon Lee reported TCP socket leaks, with a nice repro.

It seems we leak TCP sockets with the following sequence:

1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.

Each ACK will cook an skb put in error queue, from __skb_tstamp_tx(). __skb_tstamp_tx() is using skb_clone(), unless SOF_TIMESTAMPING_OPT_TSONLY was also requested.

2) If the application is also using MSG_ZEROCOPY, then we put in the error queue cloned skbs that had a struct ubuf_info attached to them.

Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc() does a sock_hold().

As long as the cloned skbs are still in sk_error_queue, socket refcount is kept elevated.

3) Application closes the socket, while error queue is not empty.

Since tcp_close() no longer purges the socket error queue, we might end up with a TCP socket with at least one skb in error queue keeping the socket alive forever.

This bug can be (ab)used to consume all kernel memory and freeze the host.

We need to purge the error queue, with proper synchronization against concurrent writers.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Linux kernel TCP socket leak due to missing error queue purge in sk_stream_kill_queues() allows local memory exhaustion and system freeze.

Vulnerability

Description

CVE-2022-50838 is a reference-count leak in the Linux kernel's networking stack that can lead to indefinite TCP socket pinning. The root cause is that sk_stream_kill_queues() does not purge the sk_error_queue. When applications use both SOF_TIMESTAMPING_TX_ACK and MSG_ZEROCOPY, cloned skbs with attached ubuf_info structures are queued to the error queue. Each such skb holds a socket reference via sock_hold(), preventing the socket from being freed.[1]

Attack

Vector and Exploitation

An attacker with the ability to create TCP sockets and enable the described socket options can trigger the leak. The exploit requires no special privileges beyond unprivileged access to the socket() and setsockopt() system calls. By repeatedly opening and closing sockets while using SOF_TIMESTAMPING_TX_ACK and MSG_ZEROCOPY, the attacker can cause the kernel to retain many TCP sockets indefinitely. Because each leaked socket consumes memory, this can be abused to exhaust system memory and freeze the host.[2]

Impact

Successful exploitation results in a local denial-of-service (DoS) condition. The kernel memory exhaustion can make the system unresponsive, requiring a hard reboot. The vulnerability is classified as high severity due to the ease of triggering it from unprivileged user space and the unavailability of any mitigation for affected systems without patching.

Mitigation

Patches are available in the Linux kernel stable releases. The fix adds proper purging of the error queue in sk_stream_kill_queues(), with synchronization against concurrent writers. System administrators should apply the latest kernel updates from their distribution. No workaround is available that does not involve changing application behavior or disabling the affected features.[3]

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

9

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

9

News mentions

0

No linked articles in our index yet.