CVE-2026-43227: Linux Kernel Race Condition Vulnerability

CVE-2026-43227 Overview

CVE-2026-43227 affects the Linux kernel's sh_tmu clocksource and clockevent driver used on Renesas SuperH and ARM platforms. The driver toggles power management and clock state at runtime through pm_runtime_*() and clk_*() calls. These helpers use regular spinlocks, but the clockevent framework invokes the driver while holding raw spinlocks. Mixing the two lock contexts triggers a lockdep "Invalid wait context" warning and creates a sleeping-in-atomic risk on PREEMPT_RT kernels. The fix forces the Timer Unit (TMU) device to remain powered on with its clock enabled after probe, eliminating the conflicting calls from atomic context.

Critical Impact
On PREEMPT_RT kernels, the locking violation can cause sleeping inside an atomic section during CPU idle broadcast handling, leading to kernel instability on affected Renesas hardware.

Affected Products

Linux kernel clocksource/drivers/sh_tmu driver
Renesas SuperH and ARM64 platforms using TMU as clockevent provider (e.g., r8a77965 Salvator-X)
PREEMPT_RT and PROVE_LOCKING enabled kernel configurations

Discovery Timeline

2026-05-06 - CVE-2026-43227 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43227

Vulnerability Analysis

The sh_tmu driver registers itself with clockevents_register_device(), which means the clockevent framework calls into the driver while holding raw spinlocks. Inside callbacks such as sh_tmu_clock_event_set_oneshot(), the driver invokes pm_runtime_resume() and clock framework helpers to power the timer on demand. Those helpers acquire dev->power.lock, a regular spinlock, from a raw-spinlock context.

Lockdep flags this as an invalid wait context. The reported call trace traverses cpuidle_enter → tick_broadcast_oneshot_control → clockevents_switch_state → sh_tmu_clock_event_set_oneshot → __pm_runtime_resume, with tick_broadcast_lock already held. On non-PREEMPT_RT builds the warning is informational, but on PREEMPT_RT kernels the regular spinlock can sleep, breaking atomicity guarantees.

Root Cause

The root cause is a runtime power management policy that conflicts with the locking rules of the clockevent framework. The driver attempted to save power by toggling pm_runtime_*() and clk_enable/disable() on each state transition. These calls reach other platform drivers that protect their state with regular (sleeping on RT) spinlocks, while the clockevent caller holds raw spinlocks [CWE-667 lock ordering / atomic context violation].

Attack Vector

This issue is a kernel correctness and stability defect rather than a remotely reachable vulnerability. Triggering requires running an affected PREEMPT_RT kernel on hardware that uses the TMU as a broadcast clockevent source and entering CPU idle states that invoke tick_broadcast_oneshot_control. No authentication or network exposure is involved.

The upstream resolution removes the runtime power and clock toggling from atomic paths and leaves the TMU device fully powered on after probe(). This eliminates the cross-context lock acquisition without changing the timer's functional behavior. Refer to the Kernel Security Fix for the upstream patch contents.

Detection Methods for CVE-2026-43227

Indicators of Compromise

Kernel log entries containing BUG: Invalid wait context referencing __pm_runtime_resume and sh_tmu_clock_event_set_oneshot.
Lockdep stack traces that include tick_broadcast_oneshot_control followed by clockevents_switch_state on Renesas ARM64 systems.
Soft lockups or scheduling-while-atomic warnings during CPU idle transitions on PREEMPT_RT kernels using sh_tmu.

Detection Strategies

Audit running kernel versions on Renesas SuperH and R-Car platforms and compare against the patched stable trees referenced in the Kernel Patch Proposal.
Build test kernels with CONFIG_PROVE_LOCKING=y and CONFIG_PREEMPT_RT=y to surface the invalid wait context warning during boot and idle stress.
Inspect /sys/devices/.../power/runtime_status for the TMU device to verify it stays active after probe on patched kernels.

Monitoring Recommendations

Forward dmesg and journalctl -k output to a centralized logging pipeline and alert on Invalid wait context and sh_tmu strings.
Track kernel package versions across embedded fleets and flag devices still running pre-patch builds of the sh_tmu driver.
Monitor cpuidle transition latency and watchdog timeouts on RT systems to catch atomic-context regressions early.

How to Mitigate CVE-2026-43227

Immediate Actions Required

Apply the upstream Linux kernel patches that keep the TMU device powered after probe, available across multiple stable branches via the Kernel Bug Fix and the Kernel Code Revision.
Rebuild and redeploy kernels for Renesas R-Car and SuperH platforms running PREEMPT_RT workloads.
Validate boot and idle behavior with lockdep enabled before promoting kernels to production fleets.

Patch Information

The fix is distributed across stable kernel trees through the commits referenced in the NVD entry, including the Kernel Code Change, Kernel Code Update, Kernel Change Request, and Kernel Improvement Notice. The patch removes runtime power and clock toggling from atomic context and unconditionally leaves the TMU running after probe().

Workarounds

Disable CONFIG_PREEMPT_RT on impacted devices until a patched kernel is available, accepting the loss of real-time guarantees.
Select an alternative clockevent source on platforms where another timer can serve broadcast duties instead of sh_tmu.
Disable CONFIG_PROVE_LOCKING only for non-RT builds where the warning is benign, while still scheduling the patch rollout.

bash

# Verify the sh_tmu fix is present in your kernel source tree
git log --oneline drivers/clocksource/sh_tmu.c | \
  grep -E '016476afef99|6f113ab549b8|88c76792180d'

# Confirm the TMU device stays powered after probe on a running system
for dev in /sys/bus/platform/devices/*tmu*; do
  echo "$dev: $(cat $dev/power/runtime_status 2>/dev/null)"
done