CVE-2025-38650

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: remove mutex_lock check in hfsplus_free_extents<br /> <br /> Syzbot reported an issue in hfsplus filesystem:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346<br /> hfsplus_free_extents+0x700/0xad0<br /> Call Trace:<br /> <br /> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606<br /> hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56<br /> cont_expand_zero fs/buffer.c:2383 [inline]<br /> cont_write_begin+0x2cf/0x860 fs/buffer.c:2446<br /> hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52<br /> generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347<br /> hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263<br /> notify_change+0xe38/0x10f0 fs/attr.c:420<br /> do_truncate+0x1fb/0x2e0 fs/open.c:65<br /> do_sys_ftruncate+0x2eb/0x380 fs/open.c:193<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock<br /> on file truncation") unlock extree before hfsplus_free_extents(),<br /> and add check wheather extree is locked in hfsplus_free_extents().<br /> <br /> However, when operations such as hfsplus_file_release,<br /> hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed<br /> concurrently in different files, it is very likely to trigger the<br /> WARN_ON, which will lead syzbot and xfstest to consider it as an<br /> abnormality.<br /> <br /> The comment above this warning also describes one of the easy<br /> triggering situations, which can easily trigger and cause<br /> xfstest&amp;syzbot to report errors.<br /> <br /> [task A] [task B]<br /> -&gt;hfsplus_file_release<br /> -&gt;hfsplus_file_truncate<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;mutex_unlock<br /> -&gt;hfsplus_write_begin<br /> -&gt;hfsplus_get_block<br /> -&gt;hfsplus_file_extend<br /> -&gt;hfsplus_ext_read_extent<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;hfsplus_free_extents<br /> WARN_ON(mutex_is_locked) !!!<br /> <br /> Several threads could try to lock the shared extents tree.<br /> And warning can be triggered in one thread when another thread<br /> has locked the tree. This is the wrong behavior of the code and<br /> we need to remove the warning.