CVE-2026-93125

What it actually does

The BPF verifier's check_kfunc_args stores an unbounded u64 var_off.value into meta->r0_size for rdonly_buf_size/rdwr_buf_size kfunc arguments, then check_kfunc_call truncates it when writing to the u32 mem_size field of the returned PTR_TO_MEM register, allowing a ~4 GiB bound instead of load-time rejection.

Why it matters to the business

Systems relying on BPF programs for networking, tracing, or security enforcement face elevated local kernel memory access risks, increasing the chance of privilege escalation or stability issues on unpatched kernels.

How an attack unfolds

An attacker loads a crafted BPF program containing a kfunc call that supplies a buf_size constant with upper 32 bits set; the verifier accepts the oversized value due to truncation, records an incorrect mem_size bound, and a subsequent memory access check against the returned register permits out-of-bounds operations.

How to fix it

Upgrade the Linux kernel to a version containing the fix that rejects rdonly_buf_size/rdwr_buf_size arguments exceeding U32_MAX at the point meta->r0_size is set; rebuild and reload any affected BPF programs after the update.

How to confirm the fix worked

Confirm the kernel source contains the added U32_MAX check in check_kfunc_args before meta->r0_size assignment; attempt to load a test BPF program with an oversized buf_size constant and verify it is now rejected at load time.

Typical attack path

1. Compile and load a BPF program using a kfunc that accepts rdonly_buf_size or rdwr_buf_size with a value exceeding U32_MAX
2. Trigger verifier path that sets meta->r0_size from the full var_off.value without bounds checking
3. Observe truncation when mem_size is written, resulting in an inflated PTR_TO_MEM bound
4. Perform memory operations that pass the incorrect size check and access kernel memory beyond intended limits

How to detect it

Review kernel audit logs and BPF verifier error messages for load attempts involving kfunc arguments named rdonly_buf_size or rdwr_buf_size; inspect bpftool prog load output or verifier logs for any acceptance of oversized constants that would previously have been truncated.

What your security team should do

• Prioritize kernel upgrades on all systems that compile or run untrusted or complex BPF programs
• Audit existing BPF code for use of kfuncs accepting buf_size arguments and ensure size values are capped below U32_MAX
• Monitor upstream stable kernel releases for backports of this verifier hardening change