CVE-2025-71180

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: interrupt-cnt: Drop IRQF_NO_THREAD flag<br /> <br /> An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as<br /> CONFIG_PROVE_RAW_LOCK_NESTING warns:<br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.18.0-rc1+git... #1<br /> -----------------------------<br /> some-user-space-process/1251 is trying to lock:<br /> (&amp;counter-&gt;events_list_lock){....}-{3:3}, at: counter_push_event [counter]<br /> other info that might help us debug this:<br /> context-{2:2}<br /> no locks held by some-user-space-process/....<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT<br /> Call trace:<br /> show_stack (C)<br /> dump_stack_lvl<br /> dump_stack<br /> __lock_acquire<br /> lock_acquire<br /> _raw_spin_lock_irqsave<br /> counter_push_event [counter]<br /> interrupt_cnt_isr [interrupt_cnt]<br /> __handle_irq_event_percpu<br /> handle_irq_event<br /> handle_simple_irq<br /> handle_irq_desc<br /> generic_handle_domain_irq<br /> gpio_irq_handler<br /> handle_irq_desc<br /> generic_handle_domain_irq<br /> gic_handle_irq<br /> call_on_irq_stack<br /> do_interrupt_handler<br /> el0_interrupt<br /> __el0_irq_handler_common<br /> el0t_64_irq_handler<br /> el0t_64_irq<br /> <br /> ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an<br /> alternative to switching to raw_spinlock_t, because the latter would limit<br /> all potential nested locks to raw_spinlock_t only.