CVE-2023-54153
Description
In the Linux kernel, the following vulnerability has been resolved:
ext4: turn quotas off if mount failed after enabling quotas
Yi found during a review of the patch "ext4: don't BUG on inconsistent journal feature" that when ext4_mark_recovery_complete() returns an error value, the error handling path does not turn off the enabled quotas, which triggers the following kmemleak:
================================================================ unreferenced object 0xffff8cf68678e7c0 (size 64): comm "mount", pid 746, jiffies 4294871231 (age 11.540s) hex dump (first 32 bytes): 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A... c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H... backtrace: [<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880 [<00000000d4e621d7>] kmalloc_trace+0x39/0x140 [<00000000837eee74>] v2_read_file_info+0x18a/0x3a0 [<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770 [<00000000340a4782>] dquot_load_quota_inode+0xc6/0x1c0 [<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4] [<000000003a0268fa>] __ext4_fill_super+0x3448/0x3910 [ext4] [<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4] [<000000004a9489c4>] get_tree_bdev+0x1dc/0x370 [<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4] [<00000000c7cb663d>] vfs_get_tree+0x31/0x160 [<00000000320e1bed>] do_new_mount+0x1d5/0x480 [<00000000c074654c>] path_mount+0x22e/0xbe0 [<0000000003e97a8e>] do_mount+0x95/0xc0 [<000000002f3d3736>] __x64_sys_mount+0xc4/0x160 [<0000000027d2140c>] do_syscall_64+0x3f/0x90 ================================================================
To solve this problem, we add a "failed_mount10" tag, and call ext4_quota_off_umount() in this tag to release the enabled qoutas.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A mount-failure path in ext4 fails to disable previously enabled quotas, causing a memory leak.
Analysis
In the Linux kernel's ext4 filesystem, when mounting a filesystem, quotas are enabled early during the operation. If a subsequent step—ext4_mark_recovery_complete()—fails, the error-handling path did not turn off the already enabled quotas. This oversight caused a memory leak, as quota-related objects (such as those allocated by v2_read_file_info and dquot_load_quota_sb) were not freed, as shown in the kernel memory debugger (kmemleak) report [1].
Exploitation and
Preconditions
This vulnerability is triggered during the mount process specifically when ext4_mark_recovery_complete() returns an error. No special privileges beyond the ability to mount an ext4 filesystem are required, but the attacker must have local access to the system to trigger the mount. The issue does not require a crafted filesystem image; it occurs with normal ext4 filesystems that cause the journal recovery completion to fail [2].
Impact
A local user who can repeatedly trigger mounts that fail in this manner can cause a kernel memory leak, eventually exhausting system memory and leading to a denial-of-service (DoS) condition. There is no indication of data corruption or privilege escalation.
Mitigation
The fix adds a cleanup step (labeled failed_mount10) in the error path that calls ext4_quota_off_umount() to properly release the enabled quotas [1][2]. Patches have been integrated into the stable kernel tree. Administrators should apply the latest kernel updates to address this issue.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
4c327b83c59eedeef86fa300577c3ca1108ebd13f99632748Vulnerability mechanics
Root cause
"Missing quota cleanup in the error path of ext4 mount when ext4_mark_recovery_complete() fails after quotas have been enabled."
Attack vector
An attacker with the ability to mount a crafted ext4 filesystem image can trigger a failure in ext4_mark_recovery_complete() after quotas have already been enabled by ext4_enable_quotas(). The error path does not call ext4_quota_off_umount(), leaving quota data structures allocated. This results in a memory leak (kmemleak) and could be used to exhaust system memory over repeated mount attempts. No special privileges beyond mount access are required.
Affected code
The vulnerability is in __ext4_fill_super() in fs/ext4/super.c. When ext4_mark_recovery_complete() returns an error after ext4_enable_quotas() has succeeded, the error path jumps to labels that do not call ext4_quota_off_umount(), leaving quota structures allocated. The patch adds a new "failed_mount10" label to properly release quotas [patch_id=5003].
What the fix does
The patch adds a new error label "failed_mount10" in __ext4_fill_super() that calls ext4_quota_off_umount() to release any quotas that were enabled before the failure occurred. The existing "failed_mount9" label (which previously handled the error path after quota enabling) is redirected to jump through "failed_mount10" first, ensuring quotas are always torn down. This closes the leak by guaranteeing that ext4_quota_off_umount() is invoked whenever the mount fails after quotas have been turned on [patch_id=5003].
Preconditions
- inputAttacker must supply a crafted ext4 filesystem image that triggers a failure in ext4_mark_recovery_complete() after quotas have been enabled.
- authAttacker must have the ability to mount a filesystem (e.g., via mount system call or removable media).
Generated on May 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.