CVE-2021-47248

What it actually does

Race condition between udp_close and udp_abort allows udp{v6}_destroy_sock to release the socket lock before destructive operations, enabling concurrent access that triggers a panic in udp_lib_lookup via use of freed or inconsistent socket state.

Why it matters to the business

Unexpected system crashes on Linux hosts processing UDP traffic can interrupt services, require reboots, and reduce availability for network-dependent applications.

How an attack unfolds

An attacker with the ability to trigger concurrent socket close and abort operations (typically via local or crafted network-induced paths) forces the race window; the missing SOCK_DEAD check allows udp_abort to act on a partially destroyed socket, resulting in the lookup panic.

How to fix it

Apply the upstream fix that sets the SOCK_DEAD flag prior to destructive actions in udp{v6}_destroy_sock; update to a Linux kernel build containing commit resolving CVE-2021-47248.

How to confirm the fix worked

Confirm kernel source contains the SOCK_DEAD guard in udp_abort and udp{v6}_destroy_sock paths; verify no panic reproduces under concurrent close/abort test cases; check kernel version against the fixed commit.

Typical attack path

1. Obtain ability to open and manipulate UDP sockets on the target host
2. Trigger close() on a UDP socket while simultaneously inducing udp_abort
3. Exploit the window where the socket lock is released before SOCK_DEAD is set
4. Cause udp_lib_lookup to dereference invalid state leading to kernel panic

How to detect it

Review kernel logs for oops or panic messages mentioning udp_lib_lookup, udp_abort, or udp_destroy_sock; inspect audit or system logs for sequences of rapid UDP socket close/abort activity around crash times.

What your security team should do

• Prioritize kernel updates on all systems exposing UDP services
• Monitor for kernel panics referencing udp_lib_lookup or udp_abort
• Apply the fix in the next maintenance window even with low EPSS due to availability impact