CVE-2022-50838: 
Linux Kernel vulnerability analysis and mitigation

CVE-2022-50838 is a resource leak vulnerability in the Linux kernel's TCP networking stack, specifically in the sk_stream_kill_queues() function, which fails to purge the socket error queue (sk_error_queue) upon socket closure. The flaw was reported by Changheon Lee and disclosed on December 30, 2025. It affects multiple stable Linux kernel branches prior to versions 4.9.337, 4.14.303, 4.19.270, 5.4.229, 5.10.163, 5.15.86, 6.0.16, 6.1.2, and 6.2. The CVSS base score is estimated as Medium (0.0 per ENISA, with Feedly categorizing it as MEDIUM) (Feedly, EUVD).

The root cause is a missing purge of sk_error_queue in sk_stream_kill_queues() when a TCP socket is closed (CWE-401: Missing Release of Memory after Effective Lifetime). The vulnerability is triggered by a specific combination of socket options: when SOF_TIMESTAMPING_TX_ACK is enabled, each ACK causes __skb_tstamp_tx() to clone an skb and place it in the error queue. If the application also uses MSG_ZEROCOPY, those cloned skbs carry a struct ubuf_info, and sock_zerocopy_alloc() calls sock_hold() for each, elevating the socket's reference count. Because tcp_close() no longer purges the error queue, closing the socket while the error queue is non-empty leaves the socket alive indefinitely, as the reference count never reaches zero (Feedly, EUVD).

A local attacker or a malicious application can exploit this vulnerability to cause unbounded kernel memory consumption by repeatedly creating and closing TCP sockets under the described conditions, ultimately exhausting all available kernel memory and freezing the host (denial of service). The vulnerability does not directly expose confidential data or allow privilege escalation, but the availability impact is severe — a complete system freeze is possible. The affected scope is limited to the local system, with no direct path to lateral movement (Feedly, EUVD).

1. Precondition: Obtain local access to a system running a vulnerable Linux kernel version (prior to the patched stable releases).
2. Socket setup: Create a TCP socket and enable SOF_TIMESTAMPING_TX_ACK via setsockopt() with SO_TIMESTAMPING.
3. Enable MSG_ZEROCOPY: Also enable MSG_ZEROCOPY on the socket, which causes sock_zerocopy_alloc() to call sock_hold() for each cloned skb placed in the error queue.
4. Generate ACKs: Send data over the socket so that ACKs are generated, causing __skb_tstamp_tx() to clone skbs with attached ubuf_info structs and enqueue them in sk_error_queue, incrementing the socket refcount each time.
5. Close without draining: Close the socket without draining the error queue. Because tcp_close() does not purge sk_error_queue, the socket's reference count remains elevated and the socket is never freed.
6. Repeat: Repeat steps 2–5 in a loop to accumulate leaked sockets and their associated kernel memory, eventually exhausting kernel memory and causing a system freeze (Feedly, EUVD).

• Logs: Kernel logs (dmesg) showing out-of-memory (OOM) killer activity or memory allocation failures related to socket or skb structures.
• System Behavior: Gradual system slowdown or freeze correlated with high kernel memory usage (/proc/meminfo showing very low MemFree and MemAvailable).
• Process: Processes repeatedly creating and closing TCP sockets with SO_TIMESTAMPING and MSG_ZEROCOPY options visible via strace or ss -e.
• Network: Large numbers of TCP sockets in unusual states visible via ss -s or /proc/net/tcp, with socket counts growing unboundedly over time.

The fix adds a call to purge sk_error_queue with proper synchronization against concurrent writers inside sk_stream_kill_queues(). Patched versions are available across all major stable kernel branches: 4.9.337, 4.14.303, 4.19.270, 5.4.229, 5.10.163, 5.15.86, 6.0.16, 6.1.2, and 6.2. Users should update their Linux kernel to the appropriate patched stable release for their branch. As a temporary workaround, avoiding the combination of SOF_TIMESTAMPING_TX_ACK and MSG_ZEROCOPY on the same socket will prevent triggering the leak (EUVD, Feedly).