CVE-2026-43227
Description
In the Linux kernel, the following vulnerability has been resolved:
clocksource/drivers/sh_tmu: Always leave device running after probe
The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime.
This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks.
This mix of spinlock contexts trips a lockdep warning.
============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90
For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel's SH TMU driver, mixing raw spinlocks with regular spinlocks for power management triggers a lockdep warning, potentially causing a denial of service.
Vulnerability
Description
The vulnerability resides in the Linux kernel's clocksource/drivers/sh_tmu driver for the SuperH Timer Unit (TMU). The TMU can serve as both a clocksource and a clockevent provider. The driver attempts to manage power and clock states dynamically, powering the device on/off and enabling/disabling its clock when not in use. However, when the TMU is used as an early platform device, it is left powered on after probe, but the clock is still managed at runtime. This creates a problematic mix of locking contexts: the clockevent framework interacts with the TMU driver using raw spinlocks, but the driver's power management calls (e.g., pm_runtime_*() and clk_*()) rely on regular spinlocks. This mismatch triggers a lockdep warning, as reported in kernels with PREEMPT_RT and PROVE_LOCKING enabled [1].
Exploitation
The issue is triggered during normal system operation when the TMU driver registers itself as a clockevent provider via clockevents_register_device(). The lockdep warning occurs because the driver holds a raw spinlock (e.g., tick_broadcast_lock) while attempting to acquire a regular spinlock (&dev->power.lock) during power management operations. This is a local denial-of-service condition that can be reproduced on affected systems, particularly those using Renesas hardware like the Salvator-X board with an R8A77965 SoC [1]. No special privileges or network access are required; the bug manifests during boot or runtime clockevent operations.
Impact
An attacker with local access or the ability to trigger clockevent operations could cause a kernel lockdep warning, which may lead to a system hang or crash, resulting in a denial of service. The CVSS v3 score of 5.5 (Medium) reflects the local nature and potential for system unavailability. The bug does not allow privilege escalation or data leakage; its primary impact is on system stability.
Mitigation
The fix is included in the Linux kernel stable tree. Patches are available in commits [1], [2], [3], and [4] (all referencing the same fix). The resolution ensures the TMU device is left running after probe, avoiding the problematic power management calls in atomic context. Users should update to a kernel version containing this fix. No workaround is documented; the issue is addressed by the patch.
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
8- git.kernel.org/stable/c/016476afef993d1201a19decc9b5b2ea1e6620f2nvdPatch
- git.kernel.org/stable/c/0e513cc6b9cea190fe342cc222b1054e7e8acfc8nvdPatch
- git.kernel.org/stable/c/6f113ab549b864c1bc57d4f89846ee335394089anvdPatch
- git.kernel.org/stable/c/79d650695773f03de36b99228a090d33d1c18264nvdPatch
- git.kernel.org/stable/c/88c76792180dffd83f1c5b9dc8fdaeb145cb94e0nvdPatch
- git.kernel.org/stable/c/b1278972b08e480990e2789bdc6a7c918bc349benvdPatch
- git.kernel.org/stable/c/bc59d5f3afe41fec5d673c27c703b761ae578d28nvdPatch
- git.kernel.org/stable/c/f0b31247e7d67a943b3a09d3cef7c0ae788d88e6nvdPatch
News mentions
0No linked articles in our index yet.