CVE-2024-42315

What it actually does

The exfat driver allocates a buffer-head array with GFP_KERNEL inside __exfat_get_dentry_set; under memory pressure this can trigger filesystem reclaim that attempts to acquire sbi->s_lock while the lock is already held by another exfat operation, producing a deadlock.

Why it matters to the business

Systems using the exfat filesystem may experience sudden hangs or complete unresponsiveness during normal file operations when memory pressure occurs, affecting availability for any workloads that rely on exfat volumes; the 178 downstream dependents increase the potential scope of impact across distributions and embedded devices.

How an attack unfolds

An attacker with local access creates or accesses a file whose directory entries exceed ES_MAX_ENTRY_NUM, forcing the GFP_KERNEL allocation path while another thread holds sbi->s_lock; under concurrent memory-reclaim activity the two threads deadlock on the lock, denying service. No named threat actors have been observed exploiting this specific issue.

How to fix it

Upgrade the Linux kernel to a version containing the fix that changes the allocation to GFP_NOFS; apply the vendor-supplied patch or distribution update that resolves the deadlock in __exfat_get_dentry_set.

How to confirm the fix worked

Confirm the running kernel contains the GFP_NOFS change in fs/exfat/dir.c or the equivalent commit; attempt to reproduce the original allocation scenario under memory pressure and verify that sbi->s_lock contention no longer produces a deadlock.

Typical attack path

1. Obtain local shell or userland execution on a Linux system mounting an exfat volume
2. Trigger repeated access to files or directories with a large number of entries
3. Induce or wait for memory pressure that activates kswapd / fs_reclaim
4. Cause the second thread to acquire sbi->s_lock inside exfat_iterate while the first thread is inside the GFP_KERNEL allocation
5. Resulting deadlock leaves the filesystem and potentially the entire system unresponsive

How to detect it

Examine kernel logs for deadlock traces involving exfat, sbi->s_lock, and fs_reclaim; look for processes stuck in exfat_iterate, exfat_readdir, or __exfat_get_dentry_set during memory-reclaim events.

What your security team should do

• Prioritize kernel updates on all systems that mount exfat volumes, especially those reachable by untrusted local users
• Monitor vendor and distribution advisories for the corrected exfat driver
• Consider restricting exfat mounts to read-only or to trusted workloads until patches are applied
• Review memory-pressure handling and I/O patterns on exfat filesystems as a temporary compensating control