CVE intelligence

CVE-2025-71180

Vulnerability intelligence

Published Jan 31, 2026Sources checked Oct 28, 2026

5.5MEDIUMCVSS out of 10

What this means

Review the available evidence

CVE-2025-71180 and is rated Medium severity with a CVSS score of 5.5. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Ubuntu Security Notices guidance

Vendor revision: Aug 21, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - Foo-over-UDP (FOU); - ARM64 architecture; - x86 architecture; - Block layer subsystem; - Drivers core; - Null block device driver; - Bluetooth drivers; - Counter interface drivers; - DMA engine subsystem; - DPLL subsystem; - GPIO subsystem; - GPU drivers; - I2C subsystem; - IIO ADC drivers; - IIO subsystem; - InfiniBand drivers; - On-Chip Interconnect management framework; - IOMMU subsystem; - IRQ chip drivers; - Modular ISDN driver; - LED subsystem; - Multiple devices driver; - Media drivers; - UACCE accelerator framework; - MMC subsystem; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Texas Instruments network drivers; - NVME drivers; - Device tree and open firmware driver; - PHY drivers; - x86 platfor

CISA KEVNot listedBased on the latest collected catalog

EPSS0.2%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2025-71180?

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.

Source: NVD