CVE-2024-50186

What it actually does

In the Linux kernel networking stack, when pf->create fails for certain protocol families that do not call sk_common_release on error paths, the allocated sk object is freed without NULLing the pointer in __sock_create, leaving a dangling reference that can be used after free.

Why it matters to the business

Affected Linux systems face elevated risk of kernel crashes, instability, or local privilege escalation; organizations must prioritize kernel updates across fleets to avoid downtime and potential compromise, especially given broad ecosystem prevalence of the Linux kernel.

How an attack unfolds

An attacker with local access triggers socket creation failure (for example via AF_PACKET in tools like arping) so that packet_create frees the sk without clearing it; subsequent kernel code paths then dereference the dangling pointer, enabling use-after-free for memory corruption or code execution. Threat actor campaigns targeting Linux kernel resource and bounds issues have demonstrated similar patterns.

How to fix it

Upgrade the Linux kernel to the fixed commit 0c3836482481200ead7b416ca80c68a29cfdaabd (or equivalent patched release) which explicitly NULLs the sk pointer on pf->create failure in __sock_create.

How to confirm the fix worked

Inspect the __sock_create function in net/socket.c to confirm the explicit NULL assignment to the sk pointer immediately after the pf->create call returns on error.

Typical attack path

1. Identify systems running vulnerable kernel versions before the fix commit
2. Trigger controlled failure in pf->create for AF_PACKET or similar families
3. Force reuse of the freed sk pointer in socket handling paths
4. Leverage resulting use-after-free for privilege escalation or denial of service

How to detect it

Search kernel logs and KASAN reports for splats referencing dangling sk pointers after socket creation failures; correlate with processes using AF_PACKET sockets such as arping; review audit logs for unusual local socket activity around the time of any crashes.

What your security team should do

• Apply the kernel patch or updated distribution packages immediately on all affected systems
• Prioritize updates on internet-facing or multi-user hosts given the low but non-zero EPSS and broad kernel deployment
• Monitor kernel logs for related KASAN reports involving sk pointers during socket creation
• Restrict unprivileged local access where feasible until patches are deployed