CVE-2025-71180: Linux Kernel Privilege Escalation Flaw

CVE-2025-71180 Overview

A race condition vulnerability exists in the Linux kernel's counter subsystem, specifically within the interrupt-cnt driver. The flaw involves an invalid wait context when the IRQ handler attempts to acquire a spinlock_t while configured with the IRQF_NO_THREAD flag. This creates a lock nesting violation that can lead to system instability or denial of service conditions.

Critical Impact

This vulnerability can cause kernel instability through improper lock acquisition in interrupt context, potentially leading to system crashes or unpredictable behavior on affected Linux systems.

Affected Products

• Linux kernel versions with the interrupt-cnt counter driver
• Systems using GPIO-based interrupt counting functionality
• ARM64 platforms utilizing the affected counter subsystem

Discovery Timeline

• 2026-01-31 - CVE CVE-2025-71180 published to NVD
• 2026-02-03 - Last updated in NVD database

Technical Details for CVE-2025-71180

Vulnerability Analysis

The vulnerability stems from an incompatible combination of interrupt handler flags and lock types in the Linux kernel's counter subsystem. When an IRQ handler is registered with the IRQF_NO_THREAD flag, it runs in hard interrupt context. However, the interrupt_cnt_isr function calls counter_push_event, which attempts to acquire counter->events_list_lock - a standard spinlock_t.

Under CONFIG_PROVE_RAW_LOCK_NESTING, the kernel's lock validator detects this as an invalid wait context violation. The kernel reports this as context {2:2} attempting to acquire a lock with context {3:3}, indicating a potential for deadlocks or priority inversion issues.

The call trace reveals the problematic execution path: when a GPIO interrupt triggers gpio_irq_handler, the interrupt propagates through handle_simple_irq to interrupt_cnt_isr, which then calls counter_push_event and attempts the invalid lock acquisition via _raw_spin_lock_irqsave.

Root Cause

The root cause is the architectural conflict between IRQF_NO_THREAD flag semantics and standard spinlock acquisition. IRQ handlers marked with IRQF_NO_THREAD cannot be threaded and run directly in hard interrupt context. In this context, only raw_spinlock_t can be safely acquired, not standard spinlock_t which may sleep on PREEMPT_RT kernels.

The kernel developers chose to remove IRQF_NO_THREAD rather than convert to raw_spinlock_t because using raw spinlocks would propagate constraints to all nested locks in the call chain, creating a broader maintenance burden.

Attack Vector

The vulnerability is triggered through normal system operation when GPIO interrupts are processed by the interrupt-cnt counter driver. The attack vector is local, requiring the presence of hardware or configuration that uses the affected driver. An attacker with local access could potentially trigger rapid interrupt generation to exploit timing windows and cause kernel panics or system instability.

The kernel's lock debugging output shows the specific conditions:

• Process context: User-space process (PID 1251)
• CPU: Single CPU (CPU 0)
• Kernel version: 6.18.0-rc1 with PREEMPT enabled
• Architecture: ARM64 (el0 exception level traces visible)

Detection Methods for CVE-2025-71180

Indicators of Compromise

• Kernel log messages containing "BUG: Invalid wait context" errors
• Stack traces showing counter_push_event in interrupt context
• System instability or unexpected reboots when using counter/interrupt-cnt functionality
• Lock validator warnings from CONFIG_PROVE_RAW_LOCK_NESTING

Detection Strategies

• Enable CONFIG_PROVE_RAW_LOCK_NESTING in kernel configuration to detect lock context violations
• Monitor kernel logs (dmesg) for lock acquisition warnings related to the counter subsystem
• Audit loaded kernel modules for interrupt_cnt presence using lsmod
• Use kernel tracing tools (ftrace) to monitor IRQ handler behavior

Monitoring Recommendations

• Configure syslog to capture and alert on kernel lock validation warnings
• Implement automated monitoring for kernel panic or BUG messages in system logs
• Deploy endpoint detection agents capable of monitoring kernel-level events
• Regularly review systems using GPIO-based interrupt counting for stability issues

How to Mitigate CVE-2025-71180

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix
• If immediate patching is not possible, avoid loading the interrupt_cnt kernel module
• Monitor affected systems for kernel instability symptoms
• Prioritize patching for systems using GPIO-based counter functionality

Patch Information

The vulnerability has been addressed through multiple commits to the Linux kernel stable branches. The fix removes the IRQF_NO_THREAD flag from the interrupt-cnt driver, allowing the IRQ handler to be threaded and safely acquire standard spinlocks.

Relevant kernel patches are available:

• Kernel Git Commit 1c5a317
• Kernel Git Commit 23f9485
• Kernel Git Commit 425886b
• Kernel Git Commit 49a6682
• Kernel Git Commit 51d2e5d
• Kernel Git Commit ef668c9

Workarounds

• Unload the interrupt_cnt module if not required: modprobe -r interrupt_cnt
• Blacklist the module to prevent automatic loading by adding blacklist interrupt_cnt to /etc/modprobe.d/blacklist.conf
• For systems requiring counter functionality, consider alternative drivers or hardware solutions until patching is completed
• Apply kernel live patching if supported by your distribution and the patch is available

# Configuration example
# Blacklist the vulnerable module until patching is complete
echo "blacklist interrupt_cnt" >> /etc/modprobe.d/blacklist-cve-2025-71180.conf

# Verify module is not loaded
lsmod | grep interrupt_cnt

# If loaded, remove the module (if not in active use)
modprobe -r interrupt_cnt

# Update initramfs to apply blacklist at boot
update-initramfs -u