CVE-2026-23025

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Jan 31, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in the Linux kernel's handling of memory pages on certain system setups can lead to crashes or corruption, so organizations should apply the available updates to keep systems stable.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Moderate
Impact: Full Compromise
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Race condition in per-CPU page allocator spinlock handling on non-SMP kernels allows interrupt during locked section leading to pcp structure corruption.

Why it matters to the business

System instability, kernel panics, or memory corruption on Linux systems compiled without SMP support, potentially affecting embedded or virtualized environments with high ecosystem prevalence in downstream distributions.

How an attack unfolds

An attacker with local access triggers page allocation and freeing paths while interrupts are enabled, causing nested spinlock attempts that corrupt the pcp data structure on UP kernels; the issue was introduced by commit 574907741599 and manifests during kcompactd or drain operations.

How to fix it

Upgrade the Linux kernel to a fixed version such as 6.1.162, 6.12.27-r0 for MinimOS packages, or the stable commit 68688fc4eab007834b4c2d740214423ba2a335a8. Apply the patch introducing local spin_lock_irqsave wrappers for all pcp->lock acquisitions.

How to confirm the fix worked

Verify the running kernel version includes the fix, enable lock debugging, and confirm absence of spinlock trylock failure BUGs during compaction and page draining under SMP=n configurations.

Typical attack path

Obtain local access to the system
Trigger memory allocation and freeing operations
Induce interrupt during spin_lock protected pcp section on SMP=n build
Exploit resulting pcp corruption for privilege escalation or denial of service

How to detect it

Examine kernel logs and dmesg for spin_dump messages, spinlock trylock failures on UP, or BUG reports involving __free_frozen_pages and kcompactd; correlate with RCU and softirq exit paths.

What your security team should do

Immediately upgrade all affected Linux kernels to patched versions given the 268 days since publication
Audit kernel build configurations disabling SMP
Test patched kernels in representative environments before rollout
Monitor kernel logs for related oops or panic events

The record

In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: prevent pcp corruption with SMP=n The kernel test robot has reported: BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) ___free_pages (mm/page_alloc.c:5295) __free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) </TASK> Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure. The problem has been introduced by commit 574907741599 ("mm/page_alloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock). [vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]

Affected packages

Ecosystem	Package	Introduced	Fixed
Linux	Kernel	0	6.1.162