CVE-2024-47746

What it actually does

In the Linux kernel FUSE implementation, a shared lock is incorrectly used when the FUSE_I_CACHE_IO_MODE bit is set instead of an exclusive lock, allowing the wait in fuse_file_cached_io_open to block indefinitely due to the race condition.

Why it matters to the business

Systems relying on FUSE filesystems may experience hangs or denial of service, disrupting file access and operations in affected Linux environments with moderate urgency given the age since disclosure.

How an attack unfolds

An attacker with local access on a system using FUSE mounts triggers concurrent file opens in cached IO mode to exploit the incorrect shared lock, leading to permanent blocking in the kernel wait path; listed threat actors in Linux kernel campaigns could leverage similar primitives though no specific exploitation of this issue is noted.

How to fix it

Apply the upstream kernel patch that enforces exclusive locking when FUSE_I_CACHE_IO_MODE is set; update to a fixed kernel version incorporating the resolution for CVE-2024-47746.

How to confirm the fix worked

Inspect kernel source for exclusive lock usage in fuse_file_cached_io_open after update, or reproduce file open sequences under cache IO mode to confirm absence of indefinite waits.

Typical attack path

1. Locate FUSE-mounted filesystem with cache IO enabled
2. Open files concurrently to set FUSE_I_CACHE_IO_MODE
3. Trigger shared lock acquisition causing indefinite wait
4. Induce system resource exhaustion or application hang

How to detect it

Examine kernel logs and process traces for threads blocked indefinitely in fuse_file_cached_io_open; correlate with FUSE mount activity and cache IO mode flags.

What your security team should do

• Prioritize kernel updates on systems using FUSE
• Review FUSE configurations for cache IO usage
• Monitor kernel logs for related wait conditions
• Test in staging environments before production rollout