Look up another CVE · open CVE-2026-90046 in the interactive tracker
CVE-2026-90046
mm/page_alloc: don't spin_trylock() in NMI on UP
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90046 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Patch series "mm/page_alloc: fixes for free_pages_nolock() on RT/UP". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
mm/page_alloc.c
- What this is
- MEMORY MANAGEMENT - PAGE ALLOCATORMAINTAINERS section matched on mm/page_alloc.c · linux-mm@kvack.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.51 | 06c76d3c389f |
| 6.15 | 7.2.5 | 68a069b40730 |
| 6.15 | 7.3 | 3105ae628fb7 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- free_pages_nolock is reached from local BPF programs (arena/bpf_map_alloc_pages and related nolock helpers) running in NMI, typically a BPF_PROG_TYPE_PERF_EVENT overflow handler installed via bpf()/perf_event_open. It is not reachable from unauthenticated network packets or in-kernel servers such as ksmbd/nfsd.
- AC:LAttack complexity, low
- Scoring assumes a uniprocessor (!CONFIG_SMP) kernel, a reasonable embedded/IoT deployment. An attacker who can attach a BPF perf-event program controls the NMI that calls free_pages_nolock and can concurrently run page-allocator work so the NMI interrupts zone->lock; the in-tree slub_kunit NMI overflow test shows this reentry is reliably triggerable.
- PR:LPrivileges required, low
- Loading the NMI BPF program requires CAP_BPF and CAP_PERFMON, which are sub-root capabilities. BPF tokens can delegate those checks into a non-init user namespace in plausible container/tracing deployments, so this is treated as low privileges rather than init-namespace root.
- UI:NUser interaction, none
- The attacker loads the BPF program, programs the PMU, and drives local memory activity themselves. No separate victim action such as mounting a filesystem or opening a crafted file is required.
- S:UScope, unchanged
- Re-entrant buddy/zone-lock corruption stays inside the kernel's own security authority and yields local privilege escalation, not a VM, IOMMU, or other cross-boundary escape.
- C:HConfidentiality impact, high
- Nested spin_trylock of zone->lock on UP lets the NMI mutate buddy freelists while the interrupted context is mid-update, corrupting page-allocator metadata. That overlapping-page primitive can be leveraged for arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The same freelist corruption is a well-known arbitrary-write and control-flow hijack primitive, and the fix commit states the bug is probably exploitable by local attackers for privilege escalation.
- A:HAvailability impact, high
- Re-entrant zone-lock and buddy updates crash the kernel via oops, panic, or a DEBUG_SPINLOCK BUG on UP, which is a full availability loss.