CVE-2024-38599 in Linux
Summary
by MITRE • 06/19/2024
In the Linux kernel, the following vulnerability has been resolved:
jffs2: prevent xattr node from overflowing the eraseblock
Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.
Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:
jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead
This breaks the filesystem and can lead to KASAN crashes such as:
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]
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 • 10/05/2025
The vulnerability CVE-2024-38599 affects the jffs2 filesystem implementation within the Linux kernel, specifically addressing a critical flaw in how extended attributes are handled during storage operations. This issue stems from the fundamental design difference between inode nodes and extended attribute nodes in the jffs2 filesystem architecture, where xattr nodes cannot be split across multiple eraseblocks unlike their inode counterparts. The flaw occurs when a requested xattr value exceeds the available space within a single eraseblock, causing the node to overflow into adjacent eraseblocks and corrupt the filesystem structure. This condition violates the core assumption that xattr nodes must remain entirely within a single eraseblock to maintain filesystem integrity and proper node ordering.
The technical implementation of this vulnerability manifests through a lack of size validation before xattr node allocation, allowing malicious or malformed inputs to create nodes that exceed the physical boundaries of their designated eraseblocks. When such oversized xattr nodes are written to flash storage, they overwrite adjacent nodes and corrupt metadata structures, leading to filesystem corruption and potential kernel crashes. The error messages indicate that nodes are being placed in incorrect locations, with CRC validation failures occurring at specific memory addresses, and the filesystem scanner detecting magic bitmask mismatches that signal fundamental structural damage. The KASAN (Kernel Address Sanitizer) reports confirm out-of-bounds memory access patterns, where the kernel attempts to read memory locations beyond allocated slab boundaries during the jffs2_sum_add_kvec operation, demonstrating that the memory corruption extends beyond simple filesystem metadata to actual kernel memory management structures.
The operational impact of this vulnerability extends far beyond simple filesystem corruption, as it can lead to complete system instability and potential data loss scenarios. When the filesystem becomes corrupted through xattr node overflows, the jffs2 scanning process fails to properly interpret the filesystem structure, resulting in kernel panics and system crashes. The vulnerability can be exploited by any process with write access to the jffs2 filesystem, making it particularly dangerous in environments where untrusted users or applications have access to filesystem operations. This flaw directly relates to CWE-129, which addresses improper validation of array indices and buffer overflows, and aligns with ATT&CK technique T1490, specifically targeting data destruction through filesystem corruption. The vulnerability's exploitation can result in persistent system instability, requiring complete filesystem rebuilds or system reinstallation, and represents a significant risk to embedded systems and devices that rely heavily on jffs2 for storage management.
Mitigation strategies for CVE-2024-38599 involve implementing proper size validation checks during xattr node creation, ensuring that the requested xattr node size never exceeds the available space within a single eraseblock minus the cleanmarker overhead. The fix should include bounds checking that prevents xattr values from creating nodes that would spill into adjacent eraseblocks, thereby maintaining the integrity of the filesystem's physical layout. System administrators should ensure that all systems running jffs2 filesystems are updated to kernel versions containing this fix, particularly in embedded environments where filesystem corruption can lead to complete device failure. Additional monitoring should be implemented to detect unusual xattr usage patterns that might indicate attempted exploitation, and regular filesystem integrity checks should be enforced to identify early signs of corruption. The vulnerability highlights the importance of proper memory management and bounds checking in embedded filesystem implementations, emphasizing that filesystem design must account for physical storage constraints rather than assuming unlimited virtual addressing capabilities.