GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: stack pointer in precision backtracking triggers a backtracking bug warning

CVSS 7.8CVE-2025-38279Kernel, userspace & hypervisorcurated

Impact

A crafted BPF program that compares a register against r10 made __mark_chain_precision() carry the stack pointer register into its bookkeeping, hitting the "verifier backtracking bug" WARN_ONCE at verifier.c:4302. The verifier then returns -EFAULT and rejects the program, so this is a reachable kernel warning rather than a demonstrated memory-safety break - the reporter's artefact is a dmesg splat and a stack trace, not corruption. On a GPU node the thing to check is panic_on_warn: hosts that run with it set will panic and take every job on the node with them, and fleets that run Cilium, bpftrace or any other BPF-heavy agent are the ones where untrusted or semi-trusted programs reach the verifier at all. Verifier state-tracking bugs are also worth patching on principle, since that code is the boundary that keeps a loaded program honest.

Who can reach it

Local. A process able to load a BPF program - CAP_BPF/CAP_SYS_ADMIN, or an unprivileged user where unprivileged BPF is still enabled. Not reachable from the network and not reachable by a tenant pod that is denied bpf(2).

What to do

Move to a stable kernel with commits 2d9a8022009d, 4265682c29c9, ac49b7560b4b or e2d2115e56c4 and reboot. Until then, the exposure is cut by keeping unprivileged BPF off (kernel.unprivileged_bpf_disabled=1) and by not granting CAP_BPF to tenant workloads; clearing panic_on_warn removes the node-level denial of service but leaves the warning.

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.