CVE-2023-52462

What it actually does

The BPF verifier incorrectly checked slot_type[0] instead of slot_type[7] when determining whether a stack slot contained a spilled pointer register, allowing a register spilled as a 1/2/4-byte value to bypass corruption checks and potentially corrupt a spilled pointer.

Why it matters to the business

Local attackers on affected Linux kernels can trigger memory corruption that may lead to kernel crashes, denial of service, or integrity violations; the issue affects the large installed base of Linux systems and requires kernel updates across distributions.

How an attack unfolds

An attacker crafts a BPF program that spills a register as a sub-register size, then manipulates the stack slot so the flawed check misses the spilled pointer; this allows subsequent operations that corrupt the pointer value, leading to memory corruption when the pointer is later used.

How to fix it

Upgrade the Linux kernel to a fixed version such as 5.10.209 or apply the commit 2757f17972d87773b3677777f5682510f13c66ef; rebuild and reboot with the patched kernel; organizations should prioritize kernels that receive the backported fix.

How to confirm the fix worked

Confirm the running kernel version contains the fix, verify the is_spilled_reg() helper is used for spilled register checks in the verifier, and test that BPF programs performing sub-register spills no longer trigger the previous incorrect behavior.

Typical attack path

1. Obtain local access on a vulnerable Linux system
2. Load a malicious BPF program that performs a sub-register spill
3. Trigger the incorrect slot_type check to corrupt the spilled pointer
4. Cause the kernel to dereference or reuse the corrupted pointer
5. Achieve memory corruption, crash, or limited integrity impact

How to detect it

Review kernel logs for BPF verifier warnings or crashes related to spilled registers; examine audit logs for unusual BPF program loads by unprivileged users; look for post-exploitation artifacts such as unexpected kernel oops or memory corruption panics after BPF activity.

What your security team should do

• Apply the kernel update to 5.10.209 or equivalent fixed version immediately on all affected systems
• Monitor for new kernel releases that include the backport and schedule rolling updates
• Restrict unprivileged BPF loading via sysctl where possible until patched
• Include this class of verifier bugs in future kernel hardening reviews