CVE-2024-50013

What it actually does

The flaw triggers a memory leak inside exfat_load_bitmap when the first root-directory entry is not a bitmap directory entry, leaving the buffer head unreleased and never reassigned.

Why it matters to the business

Systems that mount exFAT volumes may experience gradual memory exhaustion, increasing the chance of instability or forced restarts; the very low EPSS and lack of KEV listing indicate limited real-world urgency despite the kernel-wide reach.

How an attack unfolds

An attacker supplies or induces a malformed exFAT image whose root directory begins with a non-bitmap entry, causing the kernel to call exfat_load_bitmap without freeing the buffer head; repeated triggering on a mounted volume slowly depletes memory.

How to fix it

Upgrade the Linux kernel to a build containing commit f692160d3e1e5450605071b8df8f7d08d9b09a83; on Rocky Linux 8 also update the jasper package to version 2.0.14-5.el8.

How to confirm the fix worked

Confirm the running kernel contains the cited commit or the updated package version; inspect exfat source for the added bh release path and test mounting an image that previously triggered the leak.

Typical attack path

1. Obtain or craft an exFAT filesystem image whose root directory starts with a non-bitmap entry
2. Mount the image on a vulnerable kernel
3. Trigger directory parsing that reaches exfat_load_bitmap
4. Repeat the operation to accumulate unreleased buffer heads

How to detect it

Watch system memory counters and slab allocator statistics for steady growth while exFAT volumes are mounted; review dmesg or kernel logs for repeated exfat bitmap operations without corresponding buffer-head releases.

What your security team should do

• Apply the referenced kernel and package updates on all systems that may mount exFAT volumes
• Prioritize updates on multi-user or externally facing systems given the published fix date
• Review memory usage baselines for exfat-related workloads until patches are deployed