CVE-2025-40071 in Linux
Summary
by MITRE • 10/28/2025
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: Don't block input queue by waiting MSC
Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.
Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-40071 resides within the Linux kernel's tty subsystem, specifically in the n_gsm driver implementation that handles GSM (Global System for Mobile Communications) protocol communications. This flaw manifests in the GSM multiplexer channel management functionality where the input queue processing mechanism becomes unnecessarily blocked during channel opening operations. The issue is particularly significant in mobile communication contexts where reliable and timely data transmission is critical for maintaining connection integrity and service availability.
The technical root cause stems from the improper handling of Modem Status Command (MSC) messages within the GSM protocol stack. When the gsm_queue() function processes incoming frames and attempts to open a DLC (Data Link Connection Identifier) channel, it invokes gsm_dlci_open() which subsequently calls gsm_modem_update(). In basic mode operations, this sequence triggers gsm_modem_upd_via_msc() which attempts to wait for a response from the remote end before proceeding. This blocking behavior creates a deadlock scenario where the input queue becomes obstructed while awaiting a response that may never arrive or may be delayed, effectively preventing further processing of incoming data frames.
This vulnerability directly relates to CWE-362, which describes concurrent execution using shared resource vulnerabilities, and more specifically aligns with CWE-121, concerning stack-based buffer overflow conditions. The blocking behavior creates a classic deadlock scenario where the system becomes unresponsive to new incoming data while waiting for an MSC response that could potentially be lost or delayed in the communication channel. The operational impact extends beyond simple performance degradation to potential complete communication failure, particularly in environments where mobile data services rely on GSM multiplexer protocols for data transmission.
The mitigation strategy involves introducing a new function called gsm_modem_send_initial_msc() that enables sending Modem Status Command messages without waiting for responses from the remote end. This approach eliminates the blocking behavior by decoupling the MSC transmission from the input queue processing, allowing the system to continue handling incoming data while the MSC command is transmitted asynchronously. This solution specifically addresses basic encoding scenarios where MSC is valid, while appropriately avoiding MSC operations in advanced encoding modes or convergence layer type 2 implementations where such commands are not applicable. The fix aligns with ATT&CK technique T1070.004, which involves the use of system binaries to execute malicious code, by ensuring proper queue management and preventing the system from becoming unresponsive due to improper blocking mechanisms. The implementation maintains backward compatibility while resolving the concurrency issue that could lead to denial of service conditions in mobile communication infrastructure.