CVE-2023-52564

What it actually does

Use-after-free in Linux n_gsm GSM multiplexer tty driver: gsm_cleanup_mux calls gsm_dlci_release which invokes dlci_put/gsm_dlci_free without guarding against concurrent or repeated calls, allowing the DLCI pointer to be cleared while still referenced and leading to null dereference or freed memory access during tty release.

Why it matters to the business

Kernel panic or denial of service on affected Linux systems that use GSM multiplexing (common in embedded, automotive, and mobile devices); potential for local privilege escalation if the race can be reliably triggered.

How an attack unfolds

An attacker with local access triggers the GSM mux tty driver cleanup path (e.g., via crafted /dev/ttyGSMx operations or module unload) while dlci_put is still in progress, racing the reference counter so that gsm_dlci_free has already cleared the pointer checked in gsm_cleanup_mux, resulting in the observed page fault.

How to fix it

Upgrade the Linux kernel to a fixed version such as 5.10.198 or the commit 6d5c8862932d31a810b6545f7d69ecc124402c6e (or later stable releases containing the revert). Rebuild and reboot with the patched kernel; disable the n_gsm module if GSM multiplexing is not required.

How to confirm the fix worked

Confirm the running kernel version is at or above the listed fixed releases; inspect /proc/version or uname output; verify the revert commit is present in the source tree; attempt to load/unload n_gsm and exercise gsm_cleanup_mux paths in a test environment to ensure no oops occurs.

Typical attack path

1. Obtain local shell or user context on the target Linux system
2. Open or manipulate GSM multiplexer virtual tty devices to initialize DLCIs
3. Trigger driver unload, tty release, or gsm_cleanup_mux while concurrent dlci_put operations are active
4. Cause repeated dlci_put calls before gsm_dlci_free completes
5. Trigger null pointer dereference leading to kernel crash or exploitable memory corruption

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for page_fault_oops, asm_exc_page_fault, gsmtty_cleanup, tty_port_put, and release_one_tty stack traces matching the provided call trace; correlate with processes opening GSM tty devices.

What your security team should do

• Prioritize kernel upgrade on all systems exposing GSM multiplexing functionality
• Apply the patch or updated distribution kernel within standard change windows given low EPSS and no KEV listing
• Review device configurations for unnecessary use of n_gsm and blacklist the module where feasible
• Monitor kernel oops/panic logs for tty_port_put and gsmtty_cleanup symbols as an interim detection measure