CVE-2022-49941 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: avoid call of sleeping functions from atomic context
Syzkaller reports the following problem:
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2347 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1105, name: syz-executor423 3 locks held by syz-executor423/1105: #0: ffff8881468b9098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x22/0x90 drivers/tty/tty_ldisc.c:266
#1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: tty_write_lock drivers/tty/tty_io.c:952 [inline]
#1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: do_tty_write drivers/tty/tty_io.c:975 [inline]
#1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: file_tty_write.constprop.0+0x2a8/0x8e0 drivers/tty/tty_io.c:1118
#2: ffff88801b06c398 (&gsm->tx_lock){....}-{2:2}, at: gsmld_write+0x5e/0x150 drivers/tty/n_gsm.c:2717
irq event stamp: 3482 hardirqs last enabled at (3481): [] __get_reqs_available+0x143/0x2f0 fs/aio.c:946
hardirqs last disabled at (3482): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
hardirqs last disabled at (3482): [] _raw_spin_lock_irqsave+0x52/0x60 kernel/locking/spinlock.c:159
softirqs last enabled at (3408): [] asm_call_irq_on_stack+0x12/0x20
softirqs last disabled at (3401): [] asm_call_irq_on_stack+0x12/0x20
Preemption disabled at: [] 0x0
CPU: 2 PID: 1105 Comm: syz-executor423 Not tainted 5.10.137-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x107/0x167 lib/dump_stack.c:118 ___might_sleep.cold+0x1e8/0x22e kernel/sched/core.c:7304 console_lock+0x19/0x80 kernel/printk/printk.c:2347 do_con_write+0x113/0x1de0 drivers/tty/vt/vt.c:2909 con_write+0x22/0xc0 drivers/tty/vt/vt.c:3296 gsmld_write+0xd0/0x150 drivers/tty/n_gsm.c:2720 do_tty_write drivers/tty/tty_io.c:1028 [inline]
file_tty_write.constprop.0+0x502/0x8e0 drivers/tty/tty_io.c:1118 call_write_iter include/linux/fs.h:1903 [inline]
aio_write+0x355/0x7b0 fs/aio.c:1580 __io_submit_one fs/aio.c:1952 [inline]
io_submit_one+0xf45/0x1a90 fs/aio.c:1999 __do_sys_io_submit fs/aio.c:2058 [inline]
__se_sys_io_submit fs/aio.c:2028 [inline]
__x64_sys_io_submit+0x18c/0x2f0 fs/aio.c:2028 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x61/0xc6
The problem happens in the following control flow:
gsmld_write(...) spin_lock_irqsave(&gsm->tx_lock, flags) // taken a spinlock on TX data con_write(...) do_con_write(...) console_lock() might_sleep() // -> bug
As far as console_lock() might sleep it should not be called with spinlock held.
The patch replaces tx_lock spinlock with mutex in order to avoid the problem.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/19/2025
The vulnerability CVE-2022-49941 represents a critical kernel concurrency issue within the Linux kernel's tty subsystem, specifically affecting the n_gsm line discipline implementation. This flaw occurs when sleeping functions are invoked from atomic contexts, violating fundamental kernel design principles and potentially leading to system instability or crashes. The issue manifests in the GSM line discipline driver where a spinlock is held while attempting to acquire a mutex that may sleep, creating a deadlock scenario that can be exploited by malicious actors or discovered through automated testing tools like Syzkaller.
The technical root cause stems from improper locking hierarchy management within the tty subsystem's write operations. During the execution flow, the gsmld_write function acquires a spinlock (gsm->tx_lock) to protect transmit data operations, but subsequently calls console_lock() which is a sleeping function that can block indefinitely. This creates an atomic context violation where the kernel's scheduler cannot properly handle the blocking operation, leading to a kernel oops and system crash. The problem is specifically identified in the n_gsm.c driver file where the transaction lock is held while attempting to perform console output operations that require sleeping capabilities.
The operational impact of this vulnerability extends beyond simple system crashes to encompass potential denial of service conditions and security implications within kernel space. When the kernel encounters this scenario, it triggers a BUG message indicating that sleeping functions were called from invalid contexts, as demonstrated by the stack trace showing in_atomic() returning true. The vulnerability affects systems running kernel versions prior to the patch implementation, particularly those utilizing GSM line disciplines for serial communication. Attackers could potentially exploit this through crafted input that triggers the specific code path, leading to system instability or complete system lockup.
The mitigation strategy implemented in the patch involves replacing the problematic spinlock with a mutex, thereby eliminating the atomic context violation that caused the original issue. This approach aligns with the established principle of avoiding sleeping operations within atomic contexts as outlined in the Linux kernel documentation and security best practices. The fix addresses the fundamental locking hierarchy problem by ensuring that console operations, which may sleep, are not performed while holding spinlocks that prevent preemption. This solution adheres to the principle of proper kernel locking design and prevents the race condition that allowed the sleeping function to be called from an atomic context, making it compliant with both CWE-362 (Concurrency Issues) and ATT&CK technique T1068 (Exploitation for Privilege Escalation) frameworks.
The vulnerability was discovered through systematic kernel testing using the Linux Verification Center's Syzkaller framework, which systematically generates and executes random system calls to identify kernel-level issues. This automated approach demonstrates the importance of continuous kernel security testing and highlights how seemingly minor locking issues can escalate into critical system vulnerabilities. The patch resolution represents a standard defensive programming approach that prioritizes proper resource management and context awareness in kernel space operations, ensuring that the kernel maintains its stability and security guarantees under all operational conditions.