CVE-2025-37901 is a vulnerability identified in the Linux kernel specifically affecting the Qualcomm MPM (Modem Power Management) interrupt controller driver (irqchip/qcom-mpm). The issue arises because the driver does not properly handle non-wake GPIOs (General Purpose Input/Output pins) on Qualcomm chipsets. Not all GPIOs are wakeup capable; those that are not do not have a corresponding MPM pin and should be excluded from the MPM driver's interrupt handling hierarchy. The pinctrl-msm driver marks these non-wake GPIOs with the GPIO_NO_WAKE_IRQ flag, and the qcom-pdc driver correctly checks for this flag. However, the irq-qcom-mpm driver lacks this check, leading to attempts to handle interrupts for non-wake GPIOs improperly. This results in kernel crashes due to invalid memory access, as demonstrated by kernel paging faults during interrupt setup for such GPIOs. The root cause is that the IRQ domain hierarchy is not explicitly disconnected for non-wake GPIOs in the MPM driver, causing the driver to access invalid memory addresses. The fix involves adding a check for GPIO_NO_WAKE_IRQ in the irq-qcom-mpm driver, effectively removing non-wake GPIOs from the MPM interrupt hierarchy and preventing the crash. This vulnerability affects Linux kernel versions containing the specified commit hashes and is particularly relevant for devices using Qualcomm chipsets with the affected MPM driver implementation. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

For European organizations, the impact of CVE-2025-37901 depends largely on their use of Linux-based systems running on Qualcomm chipsets, especially embedded or IoT devices, industrial controllers, or robotics platforms that utilize the affected MPM driver. The vulnerability causes kernel crashes when handling interrupts for non-wake GPIOs, leading to potential denial of service (DoS) conditions. This can disrupt critical operations, cause system instability, or require device reboots, impacting availability. While it does not directly lead to privilege escalation or data leakage, the resulting instability could be exploited as part of a larger attack chain or cause operational downtime. Organizations in sectors such as manufacturing, robotics, telecommunications, and embedded systems development within Europe may be particularly affected. The vulnerability may also impact developers and vendors who build custom Linux kernels for Qualcomm-based hardware. Since no authentication or user interaction is required to trigger the crash (it occurs during interrupt setup), the attack surface includes any process or driver that configures GPIO interrupts, increasing the risk of accidental or malicious triggering. However, the lack of known exploits and the technical specificity of the vulnerability somewhat limit immediate widespread impact.

European organizations should take the following specific mitigation steps: 1) Apply the official Linux kernel patches that introduce the GPIO_NO_WAKE_IRQ check in the irq-qcom-mpm driver as soon as they become available. Monitor Linux kernel mailing lists and Qualcomm chipset vendor advisories for updates. 2) For embedded and IoT devices using Qualcomm chipsets, coordinate with hardware vendors to obtain firmware or kernel updates incorporating the fix. 3) Conduct thorough testing of kernel updates in controlled environments to ensure stability and compatibility before deployment. 4) Implement monitoring for kernel crashes and system logs related to GPIO interrupt handling to detect potential exploitation attempts or accidental triggers. 5) Limit access to systems and processes capable of configuring GPIO interrupts to trusted administrators and software components to reduce the risk of malicious triggering. 6) For critical infrastructure and industrial control systems, consider network segmentation and isolation of affected devices to minimize impact in case of a crash. 7) Maintain an inventory of devices running affected Linux kernel versions on Qualcomm chipsets to prioritize patching and risk assessment. These measures go beyond generic advice by focusing on the specific driver and chipset context of the vulnerability and emphasizing proactive patch management and monitoring.