CVE-2025-38650

What it actually does

A flawed mutex_is_locked check in hfsplus_free_extents triggers spurious kernel warnings during concurrent operations on different hfsplus files sharing the extents tree lock, introduced to avoid deadlock but incorrectly firing on legitimate multi-threaded access patterns such as file_release, setattr, unlink and get_block.

Why it matters to the business

Produces kernel warnings and test failures in hfsplus environments, creating operational noise and potential misdiagnosis of issues; low direct security risk but affects stability and monitoring in Linux systems using this filesystem, especially container-optimized deployments.

How an attack unfolds

An attacker triggers concurrent hfsplus file operations across multiple threads or processes on different files to hit the shared extents tree lock, causing the WARN_ON to fire; threat actor mentions around Linux kernel privilege escalation in container environments provide context for monitoring similar patterns though no direct code execution path is described.

How to fix it

Apply the fix removing the mutex check by updating the Linux kernel to commit 0807e4ac59a546f2346961c5e26a98901594b205; for affected Chainguard packages upgrade openjdk-8-openj9 variants to 0.53.0-r1.

How to confirm the fix worked

Confirm the warning at fs/hfsplus/extents.c:346 is absent under concurrent hfsplus workloads after patching; re-run xfstests and syzbot-style fuzzing targeting hfsplus truncation paths.

Typical attack path

1. Mount hfsplus filesystem and create multiple files
2. Execute concurrent syscalls such as ftruncate, write, release and setattr from different tasks
3. Trigger hfs_find_init/mutex_lock in one task while another reaches hfsplus_free_extents
4. Observe WARN_ON(mutex_is_locked) at extents.c:346

How to detect it

Search kernel logs and dmesg for WARNING messages referencing hfsplus_free_extents and mutex_is_locked; correlate with hfsplus_file_truncate and hfsplus_write_begin call traces under concurrent load.

What your security team should do

• Prioritize kernel updates on systems using hfsplus
• Add monitoring for hfsplus extents warnings in production logs
• Test concurrent file operations on hfsplus after remediation
• Review container workloads for hfsplus usage given associated privilege escalation threat actor activity