CVE-2023-0160

What it actually does

A race condition in the Linux kernel BPF subsystem can be triggered by a local process to induce a deadlock, resulting in a kernel panic and system crash.

Why it matters to the business

Local users on affected Linux systems can deliberately or accidentally cause complete system outages and loss of availability, disrupting operations until the host is restarted.

How an attack unfolds

An attacker with local access crafts a sequence of BPF operations that exploit the timing window in the deadlock-prone code path, forcing the kernel into an unrecoverable state and crashing the system.

How to fix it

Update the Linux kernel to the fixed commit ed17aa92dc56 or later in the mainline repository; apply the corresponding stable or distribution backport when available.

How to confirm the fix worked

Confirm the running kernel contains commit ed17aa92dc56 or an equivalent backport; re-test BPF loading and attachment under concurrent conditions to verify the deadlock no longer occurs.

Typical attack path

1. Obtain local user access on a vulnerable Linux kernel
2. Load or attach BPF programs in a specific interleaved order that triggers the race
3. Cause the kernel to enter the deadlock state
4. Observe or force a system crash

How to detect it

Review kernel logs for BPF-related oops, deadlocks, or panic messages; correlate with process execution timelines that show repeated BPF program loads or attachments immediately preceding the crash.

What your security team should do

• Prioritize kernel updates on all systems exposing BPF to untrusted local users
• Restrict unprivileged BPF loading via sysctl kernel.unprivileged_bpf_disabled=1 where feasible
• Monitor for kernel oops or panic events related to BPF