CVE-2024-44996

What it actually does

Recursive invocation of vsock recvmsg handlers after a socket is added to a BPF sockmap replaces the protocol handler and leads to unbounded recursion in __vsock_recvmsg.

Why it matters to the business

Systems using vsock sockets together with BPF sockmaps can experience kernel stack exhaustion, resulting in crashes or denial of service that disrupts container networking and orchestration workloads.

How an attack unfolds

An attacker with the ability to attach a BPF program to a vsock socket triggers the replaced recvmsg handler; subsequent calls from within the kernel's vsock receive path re-enter the BPF wrapper, creating recursion that consumes the kernel stack.

How to fix it

Update the Linux kernel to a version containing commit 921f1acf0c3cf6b1260ab57a8a6e8b3d5f3023d5 or later; for Nomad deployments upgrade to 1.4.11 or 1.5.7.

How to confirm the fix worked

Verify the running kernel contains the referenced commit or is newer than the vulnerable release; confirm Nomad binaries are at or above the listed fixed versions and test vsock socket creation under BPF sockmap attachment.

Typical attack path

1. Obtain local access or a container workload that can manipulate vsock sockets
2. Attach a BPF sockmap program to the vsock socket
3. Trigger recvmsg operations on the socket through normal or crafted traffic
4. Cause repeated recursion until kernel stack depletion occurs

How to detect it

Review kernel logs for stack overflow or recursion warnings involving vsock_bpf_recvmsg or __vsock_recvmsg; inspect audit logs for unexpected BPF program attachments to vsock sockets.

What your security team should do

• Prioritize kernel and Nomad updates on all hosts that expose vsock sockets
• Audit workloads for BPF sockmap usage with vsock and restrict where possible until patched
• Monitor for kernel oops or stack overflow reports related to vsock_bpf_recvmsg