GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel page allocator: unsafe spin_trylock in NMI context on uniprocessor builds

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

Impact

free_pages_nolock() used spin_trylock() in NMI context, which the allocator's own can_spin_trylock() documents as unsafe; the matching fix on the allocation side had already landed and the free side was missed. The upstream note says a BPF program using these features from NMI (typically tracing) on a non-SMP build may crash the kernel and is probably exploitable locally for privilege escalation. The author states they did not reproduce it and suspects no real-world user is affected. For a GPU fleet the exposure is effectively nil in practice: datacenter nodes are SMP builds, so the affected path does not exist there - carry the fix with the next kernel rather than opening a window for it.

Who can reach it

Local user able to load BPF programs that attach in NMI context, on a CONFIG_SMP=n kernel. Requires local privileges to load BPF; not reachable remotely and not reachable at all on SMP builds.

What to do

Pick up the stable kernel carrying commits 06c76d3c389f / 3105ae628fb7 / 68a069b40730 on the normal patch cadence; applying it means a node drain and reboot. No standalone mitigation is published, but restricting unprivileged BPF removes the trigger, and SMP kernels are unaffected.

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.