CVE-2025-38335: linux kernel vulnerability

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

CVE-2025-38335: linux kernel vulnerability

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

CVSS
5.5 MEDIUM
EPSS
1.74%
Known exploited
not in KEV
Product
linux kernel

What is known

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

Sources

Security newsletter

Get new CVE alerts before they become an incident

We send selected infrastructure threats in English, with practical notes for DataHouse environments.

  • DataHouse: server administration and secure cloud
  • Hostilla.pl: hosting and mail services
  • SecDNS.pl: free DNS security layer