CVE-2025-23140 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released.
However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c
To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq().
[kwilczynski: commit log]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability identified as CVE-2025-23140 resides within the Linux kernel's pci_endpoint_test module, which is designed to test PCI endpoint functionality in kernel space. This issue represents a critical resource management flaw that can lead to system instability and potential information disclosure. The problem manifests when the device management request interrupt function fails during the initialization phase of PCI endpoint testing, creating a scenario where interrupt resources are not properly cleaned up. This vulnerability falls under the category of improper resource management as classified by CWE-404, specifically involving the failure to release system resources properly after an error condition occurs.
The technical flaw occurs in the pci_endpoint_test_request_irq() function where devm_request_irq() returns an error status but the subsequent cleanup routine pci_endpoint_test_free_irq_vectors() is invoked without proper accounting for which interrupts were successfully allocated before the failure. This discrepancy creates a state where some interrupt vectors remain registered in the kernel's interrupt management system while the cleanup process assumes all vectors have been properly released. The root cause stems from the improper handling of interrupt vector allocation failures, where the code path does not adequately track which specific interrupts were successfully acquired versus those that failed during the request process. This behavior directly violates the principle of resource cleanup consistency and can be categorized under ATT&CK technique T1547.001 for privilege escalation through kernel module manipulation.
The operational impact of this vulnerability extends beyond simple resource leaks to potentially destabilize the entire kernel subsystem managing interrupt handling. When the system attempts to remove the proc entry for the interrupt directory, it encounters a non-empty directory structure due to the lingering interrupt entries, triggering kernel warnings that indicate resource leaks and potential memory corruption. The warning message specifically references fs/proc/generic.c:719 in remove_proc_entry, indicating that the kernel's process entry removal mechanism detects an inconsistency in the interrupt directory structure. This can lead to system instability, particularly in environments where PCI endpoint testing is frequently performed or where multiple test cycles are executed in quick succession. The issue may also affect system logging and monitoring capabilities, as kernel warnings can interfere with normal system operations and make debugging more difficult.
Mitigation strategies for this vulnerability require immediate implementation of proper interrupt vector accounting within the error handling paths of the pci_endpoint_test module. The recommended solution involves setting the number of remaining IRQs to test->num_irqs and explicitly releasing any IRQs that were previously allocated before the error condition occurs, through the invocation of pci_endpoint_test_release_irq(). This approach ensures that all interrupt resources are properly accounted for and released regardless of whether the initial request operation succeeds or fails. System administrators should ensure that all kernel updates containing the fix are applied immediately, particularly in production environments where PCI endpoint testing is utilized. Additionally, monitoring should be implemented to detect kernel warnings related to interrupt resource management, and the affected kernel versions should be prioritized for patching. The fix addresses the fundamental issue of inconsistent state management in kernel resource allocation and provides a robust mechanism for handling interrupt request failures while maintaining system stability and preventing potential exploitation scenarios that could leverage the resource leak for privilege escalation or denial of service attacks.