CVE-2023-54134 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
autofs: fix memory leak of waitqueues in autofs_catatonic_mode
Syzkaller reports a memory leak:
BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
[<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
[<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
[<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
[<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
[<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline]
[<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
autofs_wait_queue structs should be freed if their wait_ctr becomes zero. Otherwise they will be lost.
In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places. Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage counter to zero which is not a correct behaviour.
edit:imk This description is of course not correct. The umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the autofs mount itself. They happen independently, usually after everything mounted within the autofs file system has been expired away. If everything hasn't been expired away the automount daemon can still exit leaving mounts in place. But expires done in both cases will result in a notification that calls autofs_wait_release() with a result status. The problem case is the summary execution of of the automount daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount is umounted. end edit: imk
So in catatonic mode we should free waitqueues which counter becomes zero.
edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode() was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is removed from the list when either of these two functions are called. Consequently the wait entry will be freed by only one of these functions or by the woken process in autofs_wait() depending on the order of the calls. end edit: imk
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability described in CVE-2023-54134 represents a memory leak within the Linux kernel's autofs subsystem that specifically affects the handling of waitqueue structures during autofs catatonic mode operations. This issue manifests as a memory leak of 96-byte autofs_wait_queue structures that remain unreferenced and unreleased, as evidenced by the syzkaller memory leak detection system. The problem occurs in the context of autofs filesystem operations where the kernel manages automatic mounting and unmounting of filesystems, particularly when dealing with expiration of mount points and transition to catatonic mode. The memory leak stems from improper cleanup of waitqueue structures when their reference counters reach zero, creating a persistent memory consumption issue that can accumulate over time.
The technical flaw occurs in the autofs subsystem's handling of waitqueue management during the expiration process. When an AUTOFS_IOC_EXPIRE_MULTI ioctl is executed, the system allocates a new waitqueue structure with an initial wait_ctr value of 2. However, when wait_event_killable() is interrupted with -ERESTARTSYS return code, the waitqueue structure is not properly cleaned up due to the failure to satisfy the condition 'wq->name.name == NULL'. The system's subsequent handling of autofs_catatonic_mode() is problematic because it only decrements the usage counter to zero rather than properly freeing the waitqueue structures when their reference counts reach zero. This behavior violates standard memory management principles where structures should be freed when their reference counts drop to zero, preventing memory leaks that can degrade system performance over time.
The operational impact of this vulnerability extends beyond simple memory consumption as it represents a potential denial-of-service vector within kernel space operations. The memory leak occurs during normal autofs operations when processing expiration requests and transitioning to catatonic mode, which can happen during system shutdown or when automounted filesystems are being cleaned up. The vulnerability is particularly concerning because it affects kernel memory management directly, where leaked structures can accumulate during sustained autofs operations. According to CWE-401, this represents a classic memory leak vulnerability that can lead to resource exhaustion and system instability. The ATT&CK framework would categorize this under T1490 - Inhibit System Recovery, as the memory leak can contribute to system resource depletion and potentially affect system availability.
The proper mitigation for this vulnerability requires ensuring that waitqueue structures are correctly freed when their reference counters reach zero during catatonic mode operations. The fix must address the specific issue where autofs_catatonic_mode() only decrements usage counters rather than performing proper cleanup of waitqueue structures. This requires modifying the kernel code to properly handle the transition from normal operation to catatonic mode by ensuring that all waitqueue structures with zero reference counts are freed rather than simply marked as unused. The solution should align with kernel memory management best practices and ensure proper synchronization between the various functions that manipulate waitqueue structures. Additionally, the fix should properly handle the mutual exclusion concerns between autofs_wait_release() and autofs_catatonic_mode() calls, ensuring that waitqueue cleanup occurs exactly once per structure regardless of the call sequence. This vulnerability highlights the importance of proper reference counting and cleanup in kernel subsystems, particularly those managing complex state transitions such as autofs catatonic mode operations.