CVE-2024-36016

What it actually does

Out-of-bounds write in gsm0_receive() and gsm1_receive() when n_gsm switches between basic and advanced option modes without resetting gsm->state or gsm->len, allowing writes past gsm->buf after an attacker sends oversized data frames.

Why it matters to the business

Kernel memory corruption on Linux systems using GSM multiplexing can cause crashes, denial of service, or information disclosure, impacting stability of embedded devices, modems, and telecom infrastructure that rely on this driver.

How an attack unfolds

An attacker with local access configures the n_gsm driver in basic mode, sends a short frame header, forces a mode switch to advanced, sends excess data bytes that exceed the stale length value, then switches back to basic mode to trigger repeated writes past the allocated buffer.

How to fix it

Update the Linux kernel to a version containing commit 9513d4148950b05bc99fa7314dc883cc0e1605e5 or later; rebuild and deploy the fixed kernel across all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit 9513d4148950b05bc99fa7314dc883cc0e1605e5 or a backported equivalent by checking /proc/version or kernel build logs; test n_gsm mode switching with crafted frames in a lab environment to confirm no out-of-bounds access occurs.

Typical attack path

1. Obtain local access or control over a process that can open and configure /dev/ttyGSMx or similar serial devices
2. Configure n_gsm in basic option mode and send initial frame header with data length 1
3. Trigger reconfiguration to advanced option mode while sending additional data bytes
4. Switch back to basic mode and continue sending to cause repeated out-of-bounds writes
5. Leverage resulting memory corruption for denial of service or to attempt further privilege escalation

How to detect it

Review kernel logs for oops/panic messages mentioning gsm0_receive, gsm1_receive, or n_gsm buffer handling; look for unexpected mode reconfiguration events on serial devices in audit logs or application traces.

What your security team should do

• Prioritize kernel updates on all systems exposing n_gsm or serial multiplexing interfaces
• Restrict unprivileged access to GSM/TTY devices via device permissions and SELinux/AppArmor policies
• Monitor for kernel oops or panic logs related to gsm0_receive and gsm1_receive
• Apply the fix in the next scheduled maintenance window given the local attack vector