CVE-2025-71180: counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

Severity: medium (CVSS 5.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-01-31 · updated 2026-06-17

Description

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

Affected products

Linux kernel: from 5.13.1 before 5.15.198; from 5.16 before 6.1.161; from 6.2 before 6.6.121; from 6.7 before 6.12.66; from 6.13 before 6.18.6; 5.13, 6.19-rc1, 6.19-rc2, 6.19-rc3, 6.19-rc4, 6.19-rc5 (+3) — fixed in 5.15.198, 6.1.161, 6.12.66, 6.18.6, 6.6.121

How to fix

Upgrade to a fixed version: Linux kernel 5.15.198, 6.1.161, 6.12.66, 6.18.6. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2025-71180 or the next vulnerability affects your stack