Cloudanix VulnDB

CVE-2025-71180

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Jan 31, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A Linux kernel issue with handling certain device interrupts could make the system unstable or crash under specific conditions.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

IRQ handler for interrupt counters uses IRQF_NO_THREAD while acquiring spinlock_t, violating lock nesting rules and triggering invalid wait context in preemptible kernels, leading to potential deadlocks or instability during event processing.

Why it matters to the business

May cause kernel instability, crashes, or hangs on Linux systems using counter interrupt drivers, increasing downtime for servers and embedded devices; low likelihood reduces urgency but still requires patching for stability.

How an attack unfolds

An attacker with local access triggers IRQ events under conditions that cause lock contention in the counter driver, manifesting the nesting violation as a denial of service via system instability or crash; no remote or unauthenticated paths exist.

How to fix it

Update the Linux kernel to commit ef668c9a2261ec9287faba6e6ef05a98b391aa2b or later stable releases that remove IRQF_NO_THREAD from the interrupt-cnt handler.

How to confirm the fix worked

Verify kernel source contains the fix commit, confirm IRQF_NO_THREAD is absent from interrupt_cnt probe, and test IRQ handling under load without lockdep warnings.

Typical attack path

  1. Obtain local user access on affected Linux system
  2. Load or interact with interrupt-cnt counter driver
  3. Generate IRQ events that invoke interrupt_cnt_isr while events_list_lock is contended
  4. Trigger spinlock acquisition under threaded IRQ context to hit invalid wait condition

How to detect it

Review kernel logs for lockdep warnings mentioning counter_push_event or interrupt_cnt_isr, and check dmesg for IRQF_NO_THREAD related backtraces on IRQ paths.

What your security team should do

  • Prioritize kernel updates on systems using counter or GPIO interrupt drivers
  • Monitor for CONFIG_PROVE_RAW_LOCK_NESTING warnings in logs post-deployment
  • Apply updates within standard patch cycles given low EPSS and no KEV listing

The record

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 packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.13.0 5.15.198

Related vulnerabilities