CVE-2026-43227

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/sh_tmu: Always leave device running after probe<br /> <br /> The TMU device can be used as both a clocksource and a clockevent<br /> provider. The driver tries to be smart and power itself on and off, as<br /> well as enabling and disabling its clock when it&amp;#39;s not in operation.<br /> This behavior is slightly altered if the TMU is used as an early<br /> platform device in which case the device is left powered on after probe,<br /> but the clock is still enabled and disabled at runtime.<br /> <br /> This has worked for a long time, but recent improvements in PREEMPT_RT<br /> and PROVE_LOCKING have highlighted an issue. As the TMU registers itself<br /> as a clockevent provider, clockevents_register_device(), it needs to use<br /> raw spinlocks internally as this is the context of which the clockevent<br /> framework interacts with the TMU driver. However in the context of<br /> holding a raw spinlock the TMU driver can&amp;#39;t really manage its power<br /> state or clock with calls to pm_runtime_*() and clk_*() as these calls<br /> end up in other platform drivers using regular spinlocks to control<br /> power and clocks.<br /> <br /> This mix of spinlock contexts trips a lockdep warning.<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted<br /> -----------------------------<br /> swapper/0/0 is trying to lock:<br /> ffff000008c9e180 (&amp;dev-&gt;power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 1 lock held by swapper/0/0:<br /> ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0<br /> #0: ffff8000817ec298<br /> ccree e6601000.crypto: ARM ccree device initialized<br /> (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT<br /> Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> Call trace:<br /> show_stack+0x14/0x1c (C)<br /> dump_stack_lvl+0x6c/0x90<br /> dump_stack+0x14/0x1c<br /> __lock_acquire+0x904/0x1584<br /> lock_acquire+0x220/0x34c<br /> _raw_spin_lock_irqsave+0x58/0x80<br /> __pm_runtime_resume+0x38/0x88<br /> sh_tmu_clock_event_set_oneshot+0x84/0xd4<br /> clockevents_switch_state+0xfc/0x13c<br /> tick_broadcast_set_event+0x30/0xa4<br /> __tick_broadcast_oneshot_control+0x1e0/0x3a8<br /> tick_broadcast_oneshot_control+0x30/0x40<br /> cpuidle_enter_state+0x40c/0x680<br /> cpuidle_enter+0x30/0x40<br /> do_idle+0x1f4/0x280<br /> cpu_startup_entry+0x34/0x40<br /> kernel_init+0x0/0x130<br /> do_one_initcall+0x0/0x230<br /> __primary_switched+0x88/0x90<br /> <br /> For non-PREEMPT_RT builds this is not really an issue, but for<br /> PREEMPT_RT builds where normal spinlocks can sleep this might be an<br /> issue. Be cautious and always leave the power and clock running after<br /> probe.