CVE-2025-38650

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: remove mutexlock check in hfsplusfree_extents

Syzbot reported an issue in hfsplus filesystem:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplusfreeextents+0x700/0xad0 Call Trace: <TASK> hfsplusfiletruncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfspluswritebegin+0xc2/0xd0 fs/hfsplus/inode.c:56 contexpandzero fs/buffer.c:2383 [inline] contwritebegin+0x2cf/0x860 fs/buffer.c:2446 hfspluswritebegin+0x86/0xd0 fs/hfsplus/inode.c:52 genericcontexpandsimple+0x151/0x250 fs/buffer.c:2347 hfsplussetattr+0x168/0x280 fs/hfsplus/inode.c:263 notifychange+0xe38/0x10f0 fs/attr.c:420 dotruncate+0x1fb/0x2e0 fs/open.c:65 dosysftruncate+0x2eb/0x380 fs/open.c:193 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") unlock extree before hfsplusfreeextents(), and add check wheather extree is locked in hfsplusfreeextents().

However, when operations such as hfsplusfilerelease, hfsplussetattr, hfsplusunlink, and hfsplusgetblock are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality.

The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors.

[task A] [task B] ->hfsplusfilerelease ->hfsplusfiletruncate ->hfsfindinit ->mutexlock ->mutexunlock ->hfspluswritebegin ->hfsplusgetblock ->hfsplusfileextend ->hfsplusextreadextent ->hfsfindinit ->mutexlock ->hfsplusfreeextents WARNON(mutexis_locked) !!!

Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning.