CVE-2024-36016 in Linux
Summary
by MITRE • 05/29/2024
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/07/2026
The vulnerability CVE-2024-36016 represents a critical out-of-bounds memory access issue within the Linux kernel's tty subsystem, specifically affecting the n_gsm driver implementation. This flaw exists in the GSM frame handling mechanism where the kernel fails to properly validate data boundaries during mode transitions between basic and advanced option modes. The vulnerability stems from improper state management and validation checks that allow malicious actors to exploit memory corruption through carefully crafted frame sequences.
The technical flaw manifests in the gsm0_receive() function where the kernel maintains state variables gsm->len and gsm->state that are not properly reset during mode reconfiguration. When side A configures the n_gsm driver in basic option mode and side B sends a frame with data length 1, the system operates normally. However, when side A switches to advanced option mode and side B sends 2 data bytes that exceed the previously established gsm->len value, the kernel continues processing without proper boundary checking. This occurs because gsm->len is not utilized in advanced option mode, creating a dangerous gap in validation logic. The vulnerability becomes exploitable when side A reverts to basic option mode and side B continues sending data until gsm0_receive() writes past the allocated gsm->buf memory region.
This memory corruption vulnerability directly maps to CWE-129, which addresses improper validation of array indices, and CWE-787, concerning out-of-bounds write operations. The flaw aligns with ATT&CK technique T1059.005, representing command and scripting interpreter usage, as exploitation could involve crafting malicious frame sequences to trigger the memory corruption. The vulnerability represents a classic case of state management failure in kernel drivers where configuration changes do not properly reset internal state variables, leading to inconsistent validation logic.
The fix implemented addresses the core issue by modifying the comparison logic from equality checks to less-than-or-equal comparisons between gsm->count and gsm->len variables. This change ensures that data processing respects the actual buffer boundaries regardless of mode transitions. Additionally, the implementation introduces upper limit checks against the MAX_MRU constant in both gsm0_receive() and gsm1_receive() functions, providing defensive programming measures against potential corruption of gsm->len and gsm->mru variables. These modifications establish robust boundary validation that prevents memory corruption while maintaining the driver's functionality according to user configuration and actual payload requirements.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially allowing attackers to execute arbitrary code within the kernel space or cause system instability through controlled buffer overflows. The attack vector requires specific sequence of operations involving mode switching and crafted frame data, making it moderately complex but still exploitable in environments where untrusted data sources exist. System administrators should prioritize patching this vulnerability as it represents a potential path to privilege escalation and system compromise. The fix maintains backward compatibility while strengthening the driver's resilience against malformed frame sequences that could otherwise lead to system crashes or security breaches.