CVE-2026-90046 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: don't spin_trylock() in NMI on UP
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/[email protected]/
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified as CVE-2024-something relates to improper synchronization mechanisms within the memory management subsystem, specifically in the page allocation code path when handling Non-Maskable Interrupts on uniprocessor systems. The core technical flaw stems from the use of spin_trylock() operations during NMI context execution on UP architectures. While previous patches addressed similar issues in the page allocation side by returning NULL early to avoid locking contention, the corresponding free_pages_nolock function was overlooked. This asymmetry creates a scenario where memory deallocation attempts can trigger unsafe lock acquisition behaviors that are fundamentally incompatible with the constraints of NMI handling on single-core systems.
From an operational perspective, this vulnerability primarily affects non-SMP kernel builds where BPF programs utilizing these specific features operate within NMI contexts, typically for tracing purposes. The presence of such workloads creates a condition where the kernel may crash due to improper lock state management or potential deadlock scenarios that arise from attempting to acquire locks in interrupt context without proper preemption controls. Although initial assessments suggest limited real-world exploitation likelihood due to the specific configuration requirements involving UP systems and NMI-based BPF programs, the theoretical impact remains significant for affected deployments.
The security implications align with CWE-833 regarding improper lock handling and potentially CWE-401 if memory corruption occurs as a secondary effect of the crash conditions. In terms of ATT&CK mapping, this vulnerability could facilitate privilege escalation through local exploitation paths where an attacker might leverage kernel crashes to trigger unexpected code execution or state manipulation. The attack vector is classified as local with low complexity requirements but depends on specific system configurations and workload patterns involving BPF tracing in NMI contexts.
Mitigation strategies should focus on applying the upstream kernel patches that address this synchronization issue by ensuring consistent handling of lock operations across both allocation and deallocation paths in NMI context. System administrators running uniprocessor kernels with active BPF-based monitoring tools should prioritize updating to patched versions immediately. Additionally, organizations can reduce exposure by disabling unnecessary tracing features or restricting BPF program execution contexts where possible until comprehensive patching is implemented across all affected systems.