CVE-2023-52828

What it actually does

The BPF verifier's dead-code elimination after noreturn calls (such as bpf_throw) can leave a final call instruction as the last emitted JIT instruction; when the return address therefore falls exactly at ksym.end, bpf_prog_ksym_find and is_bpf_text_address treat the address as outside the program, producing an unreliable stack unwind and kernel panic.

Why it matters to the business

Systems running unpatched kernels may experience unexpected kernel panics when certain BPF programs that use throwing subprograms are loaded and executed, leading to service outages on hosts that rely on advanced eBPF functionality.

How an attack unfolds

An attacker with the ability to load unprivileged or privileged BPF programs constructs a call chain that ends in a noreturn subprogram; the resulting JIT image places the return address beyond the recorded program length, triggering a panic on any subsequent stack unwind.

How to fix it

Update the Linux kernel to a revision that contains commit 6058e4829696412457729a00734969acc6fd1d18 or later; rebuild and reboot with the patched kernel image. Where live patching is available, apply the vendor's kpatch or ksplice package that backports the ksym.end check.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking that bpf_prog_ksym_find treats an IP equal to ksym.end as belonging to the program; load a minimal throwing BPF program and verify that a deliberate throw no longer produces a panic and that /proc/kallsyms shows the expected program bounds.

Typical attack path

1. Obtain capability to load a BPF program (CAP_BPF or unprivileged_bpf_disabled=0)
2. Craft a program containing a conditional path that ends with a call to a subprogram that always executes bpf_throw
3. Load and attach the program so the verifier marks instructions after the throw as dead
4. Trigger execution that reaches the throwing path, causing the stack walker to consult an IP outside the recorded ksym range
5. Kernel panics during the unreliable unwind

How to detect it

Search kernel logs for "unreliable stack unwind" or "is_bpf_text_address" failures immediately after BPF program load or attachment events; correlate with audit logs showing bpf() syscalls that install programs containing call instructions near the end of their JIT image.

What your security team should do

• Prioritize kernel updates on all systems that permit unprivileged BPF or run production BPF programs with noreturn semantics
• Audit BPF program loaders and CI pipelines for use of bpf_throw or equivalent noreturn helpers
• Enable kernel panic-on-oops logging and monitor for BPF-related stack-unwind failures until patches are deployed