CVE-2024-42072

What it actually does

The BPF verifier incorrectly handled may_goto instructions with negative offsets during patching and failed to recognize actual infinite loops when may_goto_depth matched between current and visited states, allowing programs containing unbounded loops to pass verification.

Why it matters to the business

Linux systems running affected kernels remain exposed to local denial-of-service or privilege-escalation risks until kernels are updated; the large number of downstream distributions and embedded devices increases the operational footprint of the issue.

How an attack unfolds

An attacker with the ability to load unprivileged BPF programs crafts a program containing a may_goto instruction with a negative offset, submits it to the verifier, and the flawed depth comparison causes the verifier to prune exploration, accepting the program; once loaded the program can trigger kernel instability or be used as a stepping stone for further exploitation.

How to fix it

Upgrade to a fixed kernel version; the referenced stable tree commit 175827e04f4be53f3dfb57edf12d0d49b18fd939 and Linux 6.9.8 contain the correction. Reboot after installation and rebuild any out-of-tree modules as needed.

How to confirm the fix worked

Confirm the running kernel version is at or above the fixed release listed for the distribution; attempt to load a test BPF program that previously triggered the may_goto pruning bug and verify it is now rejected by the verifier.

Typical attack path

1. Obtain local access or a context that permits BPF program loading
2. Craft a BPF program that triggers the negative-offset may_goto case
3. Load the program via bpf() syscall or a framework that uses it
4. Trigger execution paths that exercise the accepted infinite loop
5. Escalate to kernel crash or arbitrary code execution

How to detect it

Review kernel logs for verifier warnings or oopses related to may_goto or bpf infinite-loop detection; inspect audit records of bpf() syscalls from untrusted users; look for unusual verifier behavior in systems that expose BPF to containers or user namespaces.

What your security team should do

• Prioritize kernel updates on all systems that allow unprivileged BPF loading
• Restrict BPF program loading via LSM or CAP_BPF capability where possible until patches are applied
• Monitor vendor advisories for backported fixes in long-term supported kernels