CVE-2022-50838

What it actually does

Failure to purge sk_error_queue in sk_stream_kill_queues allows cloned skbs holding ubuf_info references to remain after socket close when SOF_TIMESTAMPING_TX_ACK and MSG_ZEROCOPY are combined, keeping socket refcounts elevated and leaking kernel memory until exhaustion.

Why it matters to the business

Attackers or misbehaving local processes can exhaust all kernel memory on affected Linux systems, freezing the host and disrupting all services until reboot; the issue affects widely deployed kernels but carries low immediate external exploit risk.

How an attack unfolds

An attacker compiles and runs a local program that creates a TCP socket, enables SOF_TIMESTAMPING_TX_ACK, performs MSG_ZEROCOPY sends to populate the error queue with cloned skbs, then closes the socket; repeated execution leaks sockets indefinitely because tcp_close no longer drains the queue, eventually triggering OOM and system freeze.

How to fix it

Upgrade Linux kernels to a fixed release containing commit c8c1eec578a9ae2dc8f14a1846942a0b7bf29d1d or version 4.9.337 and later; rebuild and reboot into the patched kernel; where immediate upgrade is impossible, restrict untrusted local code execution and monitor memory pressure.

How to confirm the fix worked

Verify running kernel version is at or above the listed fixed releases; attempt to reproduce the socket-leak sequence in a test environment and confirm sk_error_queue is drained on close and refcounts return to expected values.

Typical attack path

1. Create TCP socket and set SOF_TIMESTAMPING_TX_ACK option
2. Perform sends with MSG_ZEROCOPY to attach ubuf_info and populate sk_error_queue via timestamping
3. Close the socket while the error queue still contains cloned skbs
4. Repeat the sequence to accumulate socket leaks and drive kernel memory consumption

How to detect it

Search system logs and kernel messages for repeated socket allocation warnings or OOM killer invocations; inspect processes that set timestamping socket options combined with zero-copy sends via strace or eBPF; correlate high sk_socket or ubuf_info object counts in slabinfo or /proc/slabinfo.

What your security team should do

• Patch all Linux hosts to a kernel containing the referenced fix within normal change windows
• Inventory systems running older kernels and prioritize those with high local-user exposure
• Add kernel memory and socket-count monitoring to detect anomalous growth before OOM
• Review any internal applications using SOF_TIMESTAMPING_TX_ACK together with MSG_ZEROCOPY