CVE-2026-23452 Linux CVE debrief

Who should care

Linux system administrators running kernels between 2.6.32 and 7.0-rc4, particularly those using SCSI subsystems or hot-pluggable devices; kernel developers maintaining out-of-tree PM runtime code; security teams monitoring for local privilege escalation or denial-of-service vectors in kernel subsystems

Technical summary

The vulnerability is a race condition (CWE-362) in the Linux kernel's PM runtime subsystem, specifically in pm_runtime_work() and pm_runtime_remove(). When a device is being removed, pm_runtime_remove() may return while pm_runtime_work() is still executing. The workqueue handler checks dev->parent and, if non-NULL and not ignoring children, attempts to idle the parent device by acquiring parent->power.lock. If the parent device has been freed between the NULL check and the lock acquisition, this results in a use-after-free on the parent's power management structure. The fix adds flush_work() in pm_runtime_remove() to synchronize with the workqueue before allowing removal to proceed. The issue requires local access and high attack complexity (CVSS 4.7), with availability impact as the primary concern.

Defensive priority

medium

Recommended defensive actions

• Apply the appropriate kernel patch for your stable branch: 5.10.253+, 5.15.203+, 6.1.167+, 6.6.130+, 6.12.78+, 6.18.20+, 6.19.10+, or 7.0-rc5+
• If running a vulnerable kernel version, monitor for KASAN slab-use-after-free warnings in dmesg, particularly in the pm_runtime_work workqueue context
• Consider enabling KASAN in test environments to detect similar race conditions
• Review custom kernel modules that interact with PM runtime for proper device reference counting
• resourceLinkAnnotations:ref-4,ref-5,ref-6,ref-7,ref-8,ref-9,ref-10

Evidence notes

The vulnerability description includes a detailed KASAN report showing the use-after-free occurring in lock_acquire() during pm_runtime_work() execution. The call trace confirms the race: pm_runtime_work() → rpm_idle() → rpm_suspend() → _raw_spin_lock() on the freed parent device. The allocation and free stacks show the parent device (scsi_target) being allocated during SCSI scanning and subsequently freed during device deletion, while the workqueue still holds a reference. The fix is confirmed by eight patch commits across stable kernel branches.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.