CVE-2023-6546 Overview
A race condition vulnerability was discovered in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, leading to a use-after-free condition on a struct gsm_dlci while restarting the gsm mux. This vulnerability could allow a local unprivileged user to escalate their privileges on the system.
Critical Impact
Local privilege escalation through use-after-free in Linux kernel GSM 0710 tty multiplexor, allowing unprivileged users to gain elevated system privileges.
Affected Products
- Linux Kernel (versions prior to patch, including 6.5 rc1-rc6)
- Fedora 39
- Red Hat Enterprise Linux 8.0 and 9.0
Discovery Timeline
- December 21, 2023 - CVE-2023-6546 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2023-6546
Vulnerability Analysis
This vulnerability combines two dangerous vulnerability classes: race conditions (CWE-362) and use-after-free (CWE-416). The flaw exists in the gsm_cleanup_mux function within the n_gsm driver (drivers/tty/n_gsm.c), which handles the GSM 0710 protocol multiplexing for serial communications.
The vulnerable code retrieves a pointer to gsm->dlci[0] before acquiring the mutex lock. In a multi-threaded environment, this creates a time-of-check-time-of-use (TOCTOU) window where another thread executing GSMIOC_SETCONF can modify or free the dlci structure between the pointer retrieval and its subsequent use.
When exploited, an attacker can trigger a use-after-free condition that corrupts kernel memory, potentially allowing arbitrary code execution in kernel context. Given that the attack requires only local access with low privileges and no user interaction, this presents a significant risk for multi-user systems and containers sharing a kernel.
Root Cause
The root cause is improper synchronization in the gsm_cleanup_mux function. The original code retrieved the dlci pointer (struct gsm_dlci *dlci = gsm->dlci[0]) at variable declaration time, before the mutex lock was acquired. This meant the pointer could become stale if another thread modified the gsm structure concurrently, leading to operations on freed memory.
Attack Vector
The attack requires local access to the system with the ability to open tty devices and set the GSM line discipline. An attacker would:
- Open a tty file descriptor and enable the n_gsm line discipline
- Spawn two concurrent threads that both call the GSMIOC_SETCONF ioctl
- Time the ioctl calls to trigger the race condition during gsm mux restart
- Exploit the resulting use-after-free to corrupt kernel memory
- Leverage the memory corruption for privilege escalation
static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc)
{
int i;
- struct gsm_dlci *dlci = gsm->dlci[0];
+ struct gsm_dlci *dlci;
struct gsm_msg *txq, *ntxq;
gsm->dead = true;
mutex_lock(&gsm->mutex);
+ dlci = gsm->dlci[0];
if (dlci) {
if (disc && dlci->state != DLCI_CLOSED) {
gsm_dlci_begin_close(dlci);
Source: GitHub Linux Commit 3c4f833
Detection Methods for CVE-2023-6546
Indicators of Compromise
- Unusual kernel crashes or panics related to the n_gsm module
- Unexpected privilege changes for user processes
- Suspicious processes accessing tty devices with GSM line discipline enabled
- Kernel log messages indicating use-after-free or memory corruption in gsm-related functions
Detection Strategies
- Monitor for processes setting the n_gsm line discipline on tty devices using audit rules
- Deploy kernel exploit detection tools that can identify use-after-free exploitation patterns
- Implement system call monitoring for GSMIOC_SETCONF ioctl operations
- Use kernel address sanitizer (KASAN) in development environments to detect memory safety issues
Monitoring Recommendations
- Enable kernel auditing for tty device operations and ioctl calls
- Monitor for suspicious multi-threaded activity targeting the same tty file descriptors
- Review system logs for kernel oops messages related to n_gsm or gsm_cleanup_mux
- Deploy endpoint detection solutions capable of identifying kernel exploitation attempts
How to Mitigate CVE-2023-6546
Immediate Actions Required
- Apply the latest kernel security patches from your Linux distribution
- If patching is not immediately possible, consider disabling the n_gsm module if not required
- Restrict access to tty devices for untrusted users
- Monitor systems for signs of exploitation attempts
Patch Information
The vulnerability has been addressed in the upstream Linux kernel via commit 3c4f8333b582487a2d1e02171f1465531cde53e3. The fix moves the retrieval of the dlci pointer to after the mutex lock is acquired, eliminating the race condition.
Red Hat has released multiple security advisories addressing this vulnerability for Enterprise Linux 8 and 9, including RHSA-2024:0930, RHSA-2024:1018, and subsequent updates. Additional details are available in Red Hat Bugzilla #2255498.
Workarounds
- Blacklist the n_gsm kernel module if GSM 0710 multiplexing is not required: echo "blacklist n_gsm" >> /etc/modprobe.d/blacklist.conf
- Restrict access to tty devices using proper file permissions and group membership
- Implement mandatory access control (SELinux/AppArmor) policies to limit ioctl operations on tty devices
- Consider using container isolation with restricted device access to limit exposure
# Configuration example
# Blacklist the n_gsm module if not needed
echo "blacklist n_gsm" | sudo tee /etc/modprobe.d/n_gsm-blacklist.conf
# Remove the module if currently loaded
sudo modprobe -r n_gsm
# Verify the module is not loaded
lsmod | grep n_gsm
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

