CVE-2026-31480

What it actually does

This is a local Linux kernel race/deadlock vulnerability in the tracing osnoise subsystem during CPU hotplug operations. A lock-order inversion between the tracing interface mutex and CPU hotplug read/write locks can cause a kernel thread stop operation to wait indefinitely while another task waits on the same lock chain. Successful triggering does not expose data or allow code execution, but it can cause a system-wide availability failure, including hung tasks, stalled CPU offline operations, or a kernel that becomes unresponsive until rebooted.

Why it matters to the business

The primary risk is service disruption on Linux systems where tracing/osnoise functionality and CPU hotplug operations are available. An attacker with local access and sufficient ability to interact with tracing or CPU state controls may be able to deliberately hang the system, causing downtime for workloads hosted on the affected machine. The current public exploitation signal is low: EPSS is approximately 0.001, unchanged over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. However, because the impact is availability loss at the kernel level, affected systems running critical workloads should still be patched through normal kernel maintenance cycles.

How an attack unfolds

An attacker first obtains local access to an affected Linux system and identifies that kernel tracing/osnoise functionality is available. The attacker then causes one task to interact with tracing interfaces that take the tracing interface lock, while concurrently initiating or racing CPU offline/hotplug activity that enters the osnoise CPU teardown path. During CPU shutdown, the kernel calls into osnoise cleanup and attempts to stop an osnoise kernel thread. That thread may enter osnoise sleep logic and attempt to acquire the same tracing interface lock while the CPU hotplug path is holding CPU hotplug synchronization. Because another task holds the tracing interface lock and then attempts to acquire CPU hotplug synchronization, the lock order reverses and the tasks can wait on each other indefinitely. The result is a kernel deadlock and denial of service rather than privilege escalation or data compromise.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the tracing osnoise CPU hotplug deadlock, specifically the change that reorders acquisition of cpus_read_lock() and interface_lock. No exact fixed package versions were provided, so track vendor advisories for the affected kernel stream and update to the first patched kernel or later. Reboot into the patched kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running. As interim mitigations, restrict local access to tracing/debug interfaces, limit membership and privileges that can write to tracefs/debugfs, avoid exposing CPU hotplug controls to untrusted users, disable or avoid use of the osnoise tracer where operationally feasible, and monitor systems that rely on dynamic CPU online/offline operations more closely until patched.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not just the installed package version, and mapping it to the vendor advisory that contains the osnoise CPU hotplug deadlock fix. On source-based or custom kernels, confirm the patch that swaps the cpus_read_lock() and interface_lock acquisition order is present in the tracing/osnoise code. Check that the system has been rebooted into the patched kernel using uname and package-manager kernel inventory. To assess exposure, determine whether tracefs/debugfs tracing interfaces are mounted and whether osnoise tracer functionality is available under /sys/kernel/tracing or /sys/kernel/debug/tracing. Review whether non-administrative users can access tracing or CPU hotplug controls. Functional validation should be performed only in a controlled test environment by exercising osnoise tracing and CPU hotplug workflows and confirming they complete without hung tasks or deadlock symptoms.

Typical attack path

1. Gain local access to an affected Linux host.
2. Confirm tracing/osnoise interfaces are enabled or accessible, typically through tracefs/debugfs tracing paths.
3. Start or manipulate osnoise tracing activity so kernel osnoise threads are active.
4. Trigger CPU hotplug activity, such as taking a CPU offline, while tracing interface operations are in progress.
5. Race the tracing interface lock against CPU hotplug locking so the vulnerable lock-order sequence is reached.
6. Cause the kernel to deadlock, leading to hung tasks, stalled CPU offline operations, or host unresponsiveness.
7. Force administrators to recover availability through reboot or out-of-band intervention.

How to detect it

Retrospective detection is difficult because exploitation looks like a kernel reliability failure rather than a distinctive intrusion event. Review kernel logs, persistent journal entries, console logs, crash dumps, and monitoring alerts for hung tasks, soft lockups, stalled CPU offline operations, or blocked kernel threads involving osnoise, tracing, kthread_stop, CPU hotplug, cpus_read_lock, cpus_write_lock, or interface_lock. Correlate those events with audit or shell history showing writes to tracefs/debugfs tracing files and CPU online/offline controls. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, auditd logs, sudo logs, EDR process telemetry, command history where available, and kernel crash dump analysis from kdump/vmcore. Look for administrative or unexpected use of tools such as rtla osnoise, trace-cmd, perf, or direct writes to /sys/kernel/tracing and /sys/devices/system/cpu/cpu*/online shortly before a hang or reboot. Absence of these artifacts does not prove non-exploitation because a full deadlock may prevent logs from being flushed.

• /sys/kernel/tracing/osnoise
• /sys/kernel/debug/tracing/osnoise
• /sys/kernel/tracing/current_tracer
• /sys/kernel/debug/tracing/current_tracer
• /sys/devices/system/cpu/cpu*/online
• rtla osnoise
• trace-cmd
• perf trace
• osnoise_cpu_die
• osnoise_sleep
• interface_lock
• cpus_read_lock
• cpus_write_lock
• kthread_stop
• CPU going offline
• task blocked for more than
• INFO: task
• blocked for more than 120 seconds
• BUG: soft lockup
• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: hung_task
• echo osnoise > /sys/kernel/tracing/current_tracer
• echo osnoise > /sys/kernel/debug/tracing/current_tracer
• echo 0 > /sys/devices/system/cpu/cpu
• echo 1 > /sys/devices/system/cpu/cpu

What your security team should do

• Prioritize patching Linux systems where local users, shared administrators, containers with elevated host access, performance-monitoring tools, or automation can interact with tracing or CPU hotplug controls.
• Include this issue in routine kernel update cycles; escalate faster for high-availability hosts because successful exploitation can require reboot-based recovery.
• Verify that production systems are actually running patched kernels after maintenance reboots.
• Restrict write access to /sys/kernel/tracing, /sys/kernel/debug/tracing, and /sys/devices/system/cpu/cpu*/online to trusted administrators only.
• Review use of osnoise, rtla osnoise, trace-cmd, perf, and related tracing tooling on multi-user systems.
• Add monitoring for CPU hotplug changes and tracing configuration changes, especially when followed by hung-task or soft-lockup messages.
• Because this is not in CISA KEV, has no known ransomware association, and has very low EPSS, treat it as a reliability-focused local DoS issue unless local attacker activity is suspected.