GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: negative CO-RE accessor index causes an out-of-bounds read and deterministic kernel crash

CVE-2026-45839Kernel, userspace & hypervisorcurated

Impact

CO-RE accessor strings were parsed with sscanf("%d") and the bounds check only guarded the upper end, so a negative index passed validation and was later cast to 0xffffffff, reading far past the BTF members array. The commit message states a crafted BPF program crashes the kernel deterministically during BPF_PROG_LOAD on any system built with CONFIG_DEBUG_INFO_BTF=y, which is the default on major distributions. That is a whole-node kill, and on a GPU node it means the in-flight training or inference work on every GPU in the box dies with it and the node needs a reboot to come back. The record rates confidentiality, integrity and availability high, but the demonstrated behaviour in the commit is an out-of-bounds read and oops rather than a proven escalation.

Who can reach it

A local user or workload holding CAP_BPF, which the commit names explicitly as the requirement. That includes any container or GPU pod granted CAP_BPF or run privileged - eBPF-based observability and CNI sidecars are the usual reason it gets handed out. Unprivileged, capability-less tenants cannot reach the path.

What to do

Take the stable kernel updates linked in the record, then drain and reboot each node; there is no runtime toggle in the fix itself. As an interim mitigation, stop granting CAP_BPF to tenant workloads and confirm kernel.unprivileged_bpf_disabled is set, which removes the reachable path for everything except the components you deliberately privileged. On fleets with a livepatch service, check whether your vendor ships this one before scheduling reboots.

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.