GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: signed 32-bit div/mod of S32_MIN diverges from the verifier, allowing out-of-bounds map access

CVSS 7.8CVE-2026-31525Kernel, userspace & hypervisorcurated

Impact

The BPF interpreter's signed 32-bit division and modulo handlers called the kernel abs() macro on s32 operands, which is undefined for the type minimum: abs(S32_MIN) returns S32_MIN unchanged on x86 and arm64, is sign-extended to 0xFFFFFFFF80000000, and makes do_div() compute the wrong result. The verifier's range tracking (scalar32_min_max_sdiv) computes the mathematically correct value, so a program can be accepted on bounds the interpreter then violates - the commit states this mismatch can be exploited for out-of-bounds map value access, which is a kernel read/write primitive and a local privilege escalation path. That matters on GPU nodes because the same hosts commonly run BPF-based CNI, service mesh and observability agents, and unprivileged BPF or a loader exposed into a pod widens who can load a program. The s64 handlers are unaffected.

Who can reach it

Local user able to load a BPF program - directly where unprivileged BPF is enabled, or via CAP_BPF/CAP_SYS_ADMIN in a pod or a BPF-using sidecar. Exploitation requires the interpreter path rather than the JIT.

What to do

Update the host kernel to a build carrying the stable fix commits below (abs_s32() replacing the eight abs((s32)...) call sites) and reboot each node; there is no in-kernel knob that fixes the mismatch. As an interim measure, keep unprivileged BPF disabled (kernel.unprivileged_bpf_disabled) and do not grant CAP_BPF to tenant workloads.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.