CVE-2021-47656 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super().
Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719
Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8)
[...]
==================================================================
The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again -----------------------------------------------------------
An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 03/25/2025
The vulnerability described in CVE-2021-47656 represents a use-after-free condition within the Linux kernel's jffs2 file system implementation, specifically in the jffs2_clear_xattr_subsystem function. This flaw occurs during the mounting process of jffs2 file systems when the kernel encounters abnormal data blocks within the file system image. The issue manifests when the first portion of a jffs2 image contains valid xattr-related inodes followed by an abnormal block, causing jffs2_scan_eraseblock() to return an error. The subsequent call sequence leads to improper memory management where jffs2_clear_xattr_subsystem() is invoked multiple times on the same memory region, resulting in a use-after-free scenario.
The technical root cause stems from the improper placement of the jffs2_clear_xattr_subsystem() function call within the error handling paths of the jffs2 mounting process. When jffs2_scan_eraseblock() fails, the kernel attempts to clean up xattr subsystem resources through jffs2_clear_xattr_subsystem() during the jffs2_build_filesystem() phase. However, this cleanup function is also called again in jffs2_do_fill_super(), creating a double-free scenario where memory allocated for xattr references is freed twice. The kernel's memory management system detects this violation through KASAN (Kernel Address Sanitizer) which reports a read operation on freed memory at address ffff8881243384e0, indicating that the system attempts to access memory that has already been deallocated. The allocated memory region belongs to the jffs2_xattr_ref cache, with a size of 48 bytes, where the actual bug occurs 40 bytes into the allocated region.
This vulnerability exposes the system to potential security risks including arbitrary code execution or system crashes, as the use-after-free condition can be exploited to corrupt kernel memory structures or manipulate execution flow. The flaw is classified under CWE-416 as a use-after-free vulnerability, which is a common class of memory safety issues in kernel space where freed memory is accessed after deallocation. From an operational perspective, this vulnerability affects any Linux system running the kernel version containing this bug and mounting jffs2 file systems, particularly those using MTD (Memory Technology Device) storage systems. The attack surface is significant as jffs2 is commonly used in embedded systems, firmware images, and systems with flash storage where the file system's error handling paths can be triggered by malformed or corrupted data.
The fix for this vulnerability involves modifying the control flow in the jffs2 mounting code to ensure jffs2_clear_xattr_subsystem() is called only once during the error cleanup phase. Specifically, the function call is moved from the 'out_inohash' error handling label to the 'out_root' label, preventing the double invocation that leads to the use-after-free condition. This change aligns with the ATT&CK framework's mitigation strategies for kernel-level vulnerabilities by ensuring proper resource cleanup and preventing memory management errors. The fix demonstrates proper defensive programming practices in kernel code, where error handling paths must be carefully constructed to avoid multiple cleanup operations on the same resources. System administrators should update their kernels to versions containing this fix to prevent exploitation, particularly in embedded systems or devices that mount jffs2 file systems from potentially untrusted sources. The vulnerability underscores the importance of careful memory management in kernel space and the need for thorough testing of error handling paths in file system implementations, especially when dealing with malformed or corrupted storage media.