CVE-2026-45957

What it actually does

This Linux kernel flaw is an RCU/softirq recursion defect in rcu_read_unlock() handling when ftrace stack tracing and softirq raising interact. A local user or workload that can cause the vulnerable kernel path to execute may trigger repeated recursion through raise_softirq_irqoff(), rcu_read_unlock_special(), ftrace stack collection, and stack unwinding, leading to a kernel deadloop, watchdog events, or system instability. The practical technical outcome is primarily local denial of service through CPU lockup or kernel hang; the assigned score also reflects potential confidentiality impact, but the public description most directly supports availability loss from an in-kernel infinite recursion/deadloop condition.

Why it matters to the business

Affected Linux systems can become unstable, hang, or require reboot, disrupting applications, containers, virtual machines, and infrastructure services running on those hosts. Because exploitation requires local access and there is no known public exploit, KEV listing, or ransomware use reported in the supplied data, urgency is lower than for remotely exploitable kernel bugs, but multi-user systems, shared compute platforms, CI runners, container hosts, and environments that allow untrusted local code should still prioritize kernel updates to avoid service outages.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux host, such as a shell account, compromised service account, malicious workload, container escape-adjacent foothold with sufficient interaction with kernel tracing paths, or another method of running code that can exercise the affected kernel behavior. The attacker then attempts to induce RCU read-unlock special handling while softirq processing and ftrace stack tracing are active. In the vulnerable code path, raise_softirq_irqoff() can be invoked without the needed deferral flag being set, allowing tracing and stack unwinding to re-enter the same sequence repeatedly. This recursive path can consume CPU and leave the kernel in a deadloop or lockup state, producing kernel warnings and stack traces that repeatedly include rcu_read_unlock_special(), raise_softirq_irqoff(), trace_event_raw_event_softirq(), and __ftrace_trace_stack(). Successful exploitation can degrade the host or make it unavailable until the kernel recovers, watchdogs intervene, or the system is rebooted.

How to fix it

Upgrade affected Linux kernels to a vendor-supported kernel release that includes the upstream fix for the RCU softirq deadloop in rcu_read_unlock() handling. No exact fixed package versions were provided, so use distribution advisories for Red Hat, Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux, Android/Linux-derived platforms, appliance vendors, and cloud images to identify the first fixed kernel for each maintained branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or tightly controlling kernel tracing/debugging interfaces where operationally feasible, and prioritizing isolation for shared compute, container, CI/CD, and bastion hosts. Reboot into the patched kernel after installation; merely installing a kernel package does not protect a running system until the fixed kernel is active.

How to confirm the fix worked

Confirm exposure by checking the running kernel version with uname -a or equivalent asset inventory and comparing it against the operating system vendor advisory for this vulnerability. Confirm remediation by verifying the host is booted into a kernel version that contains the RCU fix, not just that a patched package is installed. Review kernel changelogs or vendor errata for references to fixing rcu_read_unlock() deadloop due to softirq, raise_softirq_irqoff(), or defer_qs_pending. Validate operationally by checking that no new kernel warnings, soft lockups, RCU stall messages, or repeated stack traces involving rcu_read_unlock_special() and raise_softirq_irqoff() appear after rebooting into the fixed kernel.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel build.
2. Identify whether ftrace, stack tracing, or relevant tracing facilities are enabled or can be influenced.
3. Run a workload or trigger code paths that exercise RCU read-side unlock handling together with softirq activity.
4. Cause the vulnerable rcu_read_unlock_special() path to call raise_softirq_irqoff() in a way that re-enters ftrace stack tracing and stack unwinding.
5. Drive the kernel into repeated recursion/deadloop behavior, resulting in CPU lockup, kernel warning messages, degraded performance, or host unavailability.
6. Rely on the outage or forced reboot to disrupt applications or infrastructure running on the host.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs and system journals. Relevant sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg buffers, crash dump metadata, kdump/vmcore records, hypervisor console logs, cloud serial console logs, and monitoring alerts for kernel soft lockups or RCU stalls. Focus on repeated or recursive call traces that include rcu_read_unlock_special(), raise_softirq_irqoff(), trace_event_raw_event_softirq(), trace_buffer_unlock_commit_regs(), __ftrace_trace_stack(), stack_trace_save(), unwind_next_frame(), and arch_stack_walk(). Also investigate host reboots, watchdog resets, hung CPUs, or sudden loss of service immediately preceded by these kernel messages. Because there are no known threat actors, KEV listing, public exploit maturity, or ransomware use in the supplied data, detection should emphasize anomaly correlation: local user activity or newly deployed workloads shortly before kernel warnings, CPU lockups, or forced restarts.

• WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0
• __ftrace_trace_stack.constprop.0
• trace_buffer_unlock_commit_regs
• trace_event_buffer_commit
• trace_event_raw_event_softirq
• raise_softirq_irqoff
• __raise_softirq_irqoff
• rcu_read_unlock_special
• unwind_next_frame
• __unwind_start
• arch_stack_walk
• stack_trace_save
• __is_insn_slot_addr
• kernel_text_address
• __kernel_text_address
• unwind_get_return_address
• __flush_smp_call_function_queue
• __sysvec_call_function_single
• sysvec_call_function_single
• rcu: Fix rcu_read_unlock() deadloop due to softirq
• rcu_read_unlock() deadloop
• soft lockup
• RCU stall
• BUG: soft lockup
• watchdog: BUG: soft lockup

What your security team should do

• Inventory Linux systems and identify kernels in branches that may contain the vulnerable RCU change.
• Prioritize patching shared, multi-tenant, container-hosting, CI runner, bastion, research, and developer systems where untrusted or semi-trusted users can execute local code.
• Apply vendor kernel updates and reboot hosts into the fixed kernel; verify running kernel versions after maintenance.
• Temporarily restrict local interactive access and untrusted workload execution on unpatched high-value systems.
• Monitor kernel logs for soft lockups, RCU stalls, ftrace recursion-like traces, and repeated call stacks containing rcu_read_unlock_special() and raise_softirq_irqoff().
• Because EPSS is low, exploit maturity is reported as none, and the issue is not in KEV, schedule remediation through normal kernel patch cycles unless the affected systems allow untrusted local code or have shown instability.
• Ensure recovery procedures are ready for unpatched critical hosts, including console access, watchdog behavior, and safe reboot processes.