CVE-2024-56694

What it actually does

A recursive lock acquisition occurs in the kernel's stream verdict processing path when a BPF program returns SK_PASS, causing the same skb to be enqueued to its own socket and triggering a deadlock via nested read/write locks on sk_callback_lock.

Why it matters to the business

Systems running affected kernels can experience sudden complete freezes or hangs during normal network traffic handling, leading to unplanned downtime, loss of service availability, and potential data loss for workloads relying on BPF-based networking or security policies.

How an attack unfolds

An attacker with the ability to load or influence a stream_verdict BPF program crafts a program that returns SK_PASS without assigning a peer socket; when the kernel processes an incoming skb through this path, the recursive lock is taken and the system deadlocks. No public in-the-wild exploitation of this specific issue has been observed despite mentions of broader Linux kernel activity by espionage and financially motivated actors.

How to fix it

Upgrade the Linux kernel to a version containing commit f40ddce88593482919761f74910f42f4b84c004b or later. Rebuild and redeploy any custom BPF programs after the update. If immediate patching is not possible, avoid attaching stream_verdict programs that can return SK_PASS on sockets without a peer assigned.

How to confirm the fix worked

Confirm the running kernel contains commit f40ddce88593482919761f74910f42f4b84c004b via uname or kernel build logs. Test by attaching a stream_verdict program returning SK_PASS and verifying no deadlock occurs under load. Monitor for absence of the recursive lock pattern in kernel traces.

Typical attack path

1. Obtain privileges sufficient to load or attach a stream_verdict BPF program (CAP_BPF or equivalent).
2. Load a program that returns SK_PASS on the target socket without setting a peer socket.
3. Trigger network traffic that causes the verdict program to execute on an skb.
4. Observe the resulting deadlock and system unresponsiveness.

How to detect it

Review kernel logs and dmesg for hung task warnings or deadlock messages referencing sk_psock_strp_data_ready or sk_callback_lock. Correlate with BPF program load/attach events in audit logs or /sys/kernel/debug/tracing. Check for repeated SK_PASS returns from stream_verdict programs in system call or BPF event traces.

What your security team should do

• Prioritize kernel upgrades on all systems exposing BPF networking or security features.
• Audit existing BPF programs for stream_verdict usage returning SK_PASS.
• Implement kernel live-patching where available for critical production systems.
• Update monitoring to detect kernel deadlocks or hung tasks related to sk_psock processing.