7.8 HIGH
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Local (L)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L)
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): High (H)
- Integrity (I): High (H)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Local (L)
- Modified Attack Complexity (MAC): Low (L)
- Modified Privileges Required (MPR): Low (L)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): High (H)
- Modified Scope (MS): Unchanged (U)
- Modified Integrity (MI): High (H)
- Modified Availability (MA): High (H)
Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
mm/page_alloc: don't spin_trylock() in NMI on UP
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/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.
References
Affected products
- =<7.2.*
- ==6.15
- <6.15
- <3105ae628fb785d48b49256468be4f21a7b3cfc0
- =<6.18.*
- =<*
- <68a069b407303e71db371df85036101e8ff59280
- <06c76d3c389ff504052f64b1acee44651bd847fa