CVE-2026-43227

What it actually does

This is a Linux kernel availability flaw in the Renesas SH TMU clocksource/clockevent driver. The driver can call runtime power-management and clock-management routines while operating in clockevent paths that hold raw spinlocks. On PREEMPT_RT kernels, where regular spinlocks may sleep, this can create an invalid locking context and trigger lockdep warnings or unstable behavior in timer, idle, or clockevent handling. The practical impact is denial of service through kernel instability, hangs, or crashes on affected systems using the sh_tmu driver, especially real-time Linux builds on relevant Renesas platforms. Confidentiality and integrity are not directly affected.

Why it matters to the business

Affected real-time or embedded Linux systems may become unstable or unavailable, which can disrupt industrial, automotive, networking, appliance, or edge workloads that rely on predictable timing and uptime. The risk is most relevant to systems using Renesas SH TMU timer hardware with PREEMPT_RT or lock-debugging configurations. Public exploitation is not currently known, the EPSS score is very low and flat, and it is not in CISA KEV, so broad internet-scale exploitation is unlikely; however, downtime on embedded or real-time devices can still have significant operational impact.

How an attack unfolds

An attacker would first need local access to a vulnerable Linux system with the affected sh_tmu driver in use. Because the vulnerable behavior occurs in kernel timer and clockevent paths, exploitation would focus on repeatedly exercising CPU idle, timer, scheduling, or clockevent transitions until the driver attempts runtime power or clock operations from an invalid lock context. On susceptible PREEMPT_RT systems, this can cause kernel warnings, lock dependency failures, hangs, or crashes, resulting in denial of service. There is no indication from the provided data of remote exploitation, privilege escalation, ransomware use, or active exploitation by named threat actors.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the sh_tmu driver behavior. The corrective change is to keep the TMU device powered and its clock running after probe instead of enabling/disabling power and clocks from clockevent paths. No exact fixed package versions were provided, so use the fixed kernel released by the Linux distribution, device vendor, board support package maintainer, or embedded Linux supplier for the affected platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling unnecessary user access, and testing whether PREEMPT_RT builds using sh_tmu can be temporarily replaced with a non-RT or vendor-mitigated kernel if operationally acceptable. Kernel mitigations should be validated carefully on real-time systems because timer and clocksource changes can affect latency and scheduling behavior.

How to confirm the fix worked

Confirm whether the system uses the affected driver by checking kernel configuration, loaded drivers, device tree entries, and boot logs for sh_tmu or Renesas TMU timer initialization. Validate remediation by booting the updated kernel and confirming that the running kernel version or vendor build contains the sh_tmu fix. Review dmesg and persistent kernel logs under normal and stress conditions for absence of lockdep warnings involving sh_tmu_clock_event_set_oneshot, __pm_runtime_resume, tick_broadcast_lock, or Invalid wait context. On PREEMPT_RT systems, run representative real-time, idle-state, suspend/resume, and timer-stress workloads to confirm there are no kernel warnings, hangs, latency regressions, or clockevent failures.

Typical attack path

1. Gain local access to a Linux system using the affected Renesas SH TMU timer driver.
2. Confirm the system is running a vulnerable kernel build, especially a PREEMPT_RT or lock-debugging configuration.
3. Trigger repeated timer, idle, scheduling, or clockevent state transitions that invoke the sh_tmu clockevent path.
4. Cause the driver to call runtime power-management or clock-management routines while a raw spinlock context is active.
5. Induce kernel instability, lockdep failures, hang, panic, or other denial-of-service condition.

How to detect it

To determine whether this issue was already triggered, collect kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, serial console logs, crash dumps, pstore/ramoops, and any embedded device watchdog reset logs. Search for lockdep reports, invalid wait context warnings, kernel panics, hangs, watchdog resets, or call traces involving the sh_tmu timer driver, runtime power management, clockevents, or tick broadcast handling. Relevant artifacts include stack traces containing sh_tmu_clock_event_set_oneshot, __pm_runtime_resume, clockevents_switch_state, tick_broadcast_set_event, __tick_broadcast_oneshot_control, cpuidle_enter_state, or do_idle. Because this is a local denial-of-service condition with no known public exploit indicators, detection should focus on kernel instability evidence rather than network indicators. Correlate matching kernel messages with local login records, process execution telemetry, workload launches, or scheduled jobs to identify whether an untrusted local user or process may have intentionally triggered repeated timer or idle transitions.

• BUG: Invalid wait context
• lockdep warning
• __pm_runtime_resume
• sh_tmu_clock_event_set_oneshot
• clockevents_switch_state
• tick_broadcast_set_event
• __tick_broadcast_oneshot_control
• tick_broadcast_lock
• cpuidle_enter_state
• cpuidle_enter
• do_idle
• swapper/0 is trying to lock
• &dev->power.lock
• clocksource/drivers/sh_tmu
• sh_tmu
• TMU device
• PREEMPT_RT
• PROVE_LOCKING

What your security team should do

• Prioritize inventory of Linux systems using Renesas SH TMU timer hardware, especially embedded and real-time PREEMPT_RT deployments.
• Obtain and schedule deployment of a vendor or distribution kernel that includes the sh_tmu fix.
• Treat exposed local-user or multi-tenant embedded systems as higher priority because exploitation requires local code execution.
• Review kernel logs for historical lockdep, timer, idle, or clockevent warnings that match the vulnerable path.
• Restrict local interactive access and untrusted workload execution until patched.
• Test the patched kernel in a staging or hardware-in-the-loop environment before production rollout, with emphasis on real-time latency and timer behavior.
• If no vendor kernel is available, consult the platform maintainer about backporting the upstream driver change.
• Continue monitoring vendor advisories because no fixed versions were supplied in the input.