CVE-2025-38335

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT<br /> <br /> When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in<br /> hard irq context, but the input_event() takes a spin_lock, which isn&amp;#39;t<br /> allowed there as it is converted to a rt_spin_lock().<br /> <br /> [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0<br /> ...<br /> [ 4054.290195] __might_resched+0x13c/0x1f4<br /> [ 4054.290209] rt_spin_lock+0x54/0x11c<br /> [ 4054.290219] input_event+0x48/0x80<br /> [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78<br /> [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438<br /> [ 4054.290257] hrtimer_interrupt+0xe4/0x240<br /> [ 4054.290269] arch_timer_handler_phys+0x2c/0x44<br /> [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c<br /> [ 4054.290297] handle_irq_desc+0x40/0x58<br /> [ 4054.290307] generic_handle_domain_irq+0x1c/0x28<br /> [ 4054.290316] gic_handle_irq+0x44/0xcc<br /> <br /> Considering the gpio_keys_irq_isr() can run in any context, e.g. it can<br /> be threaded, it seems there&amp;#39;s no point in requesting the timer isr to<br /> run in hard irq context.<br /> <br /> Relax the hrtimer not to use the hard context.