CVE-2024-36016: tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
In the Linux kernel, the following vulnerability has been resolved:
tty: ngsm: fix possible out-of-bounds in gsm0receive()
Assuming the following: - side A configures the ngsm 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 gsm0receive() 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 MAXMRU in gsm0receive() and gsm1receive() 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.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
tty: ngsm: fix possible out-of-bounds in gsm0receive()
The Linux kernel CVE team has assigned CVE-2024-36016 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052947-CVE-2024-36016-d30a@gregkh/T
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.137-1Fixed in 6.1.135-1Fixed in 6.12.27-1 - Upgrade
Upgrade
redhat/kernelto a version that resolves this vulnerability.Fixed in 6.10 - Configuration
In gsm0_receive(), fix the bounds check by changing the gsm->count to gsm->len comparison from equal to less than (i.e., use gsm->count < gsm->len) to prevent out-of-bounds when validating frame payload length.
Linux kernel tty: n_gsm gsm->count comparison vs gsm->len = less-than (gsm->count < gsm->len) instead of equal / (gsm->count == gsm->len) - Configuration
After switching n_gsm between basic and advanced option modes, reset gsm->state and gsm->len (so they cannot retain stale values) and ensure data length limiting still uses user configuration and actual payload size, including in advanced option mode.
Linux kernel tty: n_gsm advanced option mode handling = reset gsm->state and gsm->len after reconfiguration / ensure gsm->len is used as upper bound - Configuration
In gsm0_receive() and gsm1_receive(), add upper limit checks against the constant MAX_MRU to harden against memory corruption of gsm->len and gsm->mru.
Linux kernel tty: n_gsm upper limit checks = add upper limit checks against constant MAX_MRU in gsm0_receive() and gsm1_receive() - Compensating control
Apply the upstream fix for CVE-2024-36016 from the Linux kernel tty: n_gsm patch; treat affected systems as potentially vulnerable until the fix is applied.
Event History
Frequently Asked Questions
What is the severity of CVE-2024-36016?
The severity of CVE-2024-36016 is classified as high due to the potential for out-of-bounds access.
How do I fix CVE-2024-36016?
To fix CVE-2024-36016, update to the latest kernel versions: 6.10 or specific versions outlined in Debian package updates.
What software is affected by CVE-2024-36016?
CVE-2024-36016 affects specific versions of the Red Hat kernel and Debian Linux packages.
Is CVE-2024-36016 present in older kernel versions?
Yes, CVE-2024-36016 is present in older kernel versions prior to the specified fixes.
What components are involved in CVE-2024-36016?
CVE-2024-36016 involves the tty subsystem and the n_gsm protocol in the Linux kernel.