CVE-2025-37741 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1]
WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted -------------------------------------------- syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(&(imap->im_aglock[index]));
lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515
#1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]
#1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026
#2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline]
validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline]
__mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]
duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline]
diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline]
__se_sys_mkdirat fs/namei.c:4293 [inline]
__x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability CVE-2025-37741 resides within the Linux kernel's JFS (Journaled File System) implementation, specifically in how it handles the copying of inode attributes during directory creation operations. The flaw manifests when the system attempts to read corrupted metadata from disk in raw mode, leading to the assignment of an invalid nlink value of zero to an inode during the copy_from_dinode() operation. This condition triggers a deadlock scenario within the diFree() function, which is part of the JFS inode management subsystem. The root cause stems from a lack of validation on the nlink field prior to its assignment to the in-memory inode structure, creating a condition where a zero nlink value can propagate through the system and ultimately lead to recursive locking issues.
The technical exploitation pathway begins with a malformed ioctl call using LOOP_SET_STATUS64 with an incorrect offset value of 4, which invalidates the mapping of a mounted loop device. This misconfiguration causes the read_metapage() function to access disk inode data in raw mode, resulting in corrupted AIT (Attribute Information Table) page data. During diReadSpecial() processing, this corrupted data gets parsed and the copy_from_dinode() function incorrectly assigns a zero nlink value to the iag (inode allocation group) inode. The vulnerability is further exacerbated by the fact that the kernel's locking mechanism detects a recursive lock attempt when diFree() tries to acquire the same lock that is already held by diAlloc(), creating a classic deadlock scenario that prevents system progression. This type of vulnerability aligns with CWE-367, which addresses Time-of-Check to Time-of-Use (TOCTOU) flaws, and falls under ATT&CK technique T1490, specifically targeting data destruction through file system corruption.
The operational impact of this vulnerability extends beyond simple system deadlock, potentially leading to complete system hang conditions that can only be resolved through manual intervention or system reboot. The deadlock occurs in the JFS inode management layer, specifically within the diFree() function, which is responsible for freeing inode resources during directory operations. Attackers could exploit this by carefully crafting loop device operations that trigger the corrupted metadata path, effectively causing denial of service conditions on systems running JFS filesystems. The vulnerability is particularly concerning because it can be triggered through standard filesystem operations and does not require elevated privileges beyond normal user access. The syzbot report indicates that this vulnerability was found in a kernel version 6.12.0-rc7, suggesting it affects recent kernel development branches and potentially impacts production systems that have not yet applied the necessary patches. The locking behavior observed during the deadlock indicates a fundamental flaw in the inode management locking hierarchy, where the same lock is attempted to be acquired twice in the same execution context, which violates proper locking protocol adherence.
Mitigation strategies for CVE-2025-37741 must focus on implementing proper validation of inode attributes before assignment to in-memory structures. The recommended fix involves adding a pre-check for the nlink value in the copy_from_dinode() function to ensure that zero values are not copied from disk to memory, preventing the propagation of invalid inode states. Additionally, system administrators should ensure that all JFS filesystems are updated with the latest kernel patches that address this specific deadlock condition. The patch should include enhanced error handling for corrupted disk metadata and proper validation of inode attributes during read operations. Monitoring for loop device operations that might trigger the vulnerability should be implemented, as well as ensuring that proper locking nesting annotations are maintained throughout the JFS subsystem to prevent recursive lock acquisitions. System hardening measures should also include ensuring that loop devices are properly validated before being mounted and that filesystem operations are protected against malformed ioctl parameters. This vulnerability underscores the importance of proper input validation in kernel space operations and highlights the critical need for robust locking mechanisms in filesystem implementations to prevent deadlocks and maintain system stability.