Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:Input: gpio-keys - fix a sleep while atomic with PREEMPT_RTWhen enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs inhard irq context, but the input_event() takes a spin_lock, which isn'tallowed 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/0xccConsidering the gpio_keys_irq_isr() can run in any context, e.g. it canbe threaded, it seems there's no point in requesting the timer isr torun in hard irq context.Relax the hrtimer not to use the hard context.
No PoCs from references.
- https://github.com/w4zu/Debian_security