CVE-2026-63808

What it actually does

This is a Linux kernel use-after-free in the exFAT filesystem driver, specifically in exfat_find_dir_entry(). A buffer_head returned by exfat_get_dentry() can be released with brelse() before code later dereferences a directory-entry pointer that still points into the released buffer. A crafted exFAT filesystem image with long filename entries and same-hash collisions can force execution into the affected TYPE_EXTEND path, producing a stale memory read. In hardened/debug kernels this has been demonstrated as a KASAN use-after-free and page fault. In production kernels, practical exploitability is not established from the available information, but kernel use-after-free bugs can potentially lead to denial of service and, depending on memory reuse conditions and hardening, may create a path toward kernel memory corruption or privilege escalation.

Why it matters to the business

Systems that mount untrusted exFAT media or images could be crashed or destabilized by a malicious filesystem. The most exposed environments are endpoints, kiosks, file-ingestion systems, forensic workstations, virtualization hosts, backup/media-processing systems, and servers that automatically mount removable drives or user-supplied disk images. Although this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity indicated, the high CVSS score reflects the potential severity of kernel-level memory safety flaws if reliable exploitation becomes available.

How an attack unfolds

An attacker prepares a malformed exFAT filesystem image containing directory entries designed to exercise the vulnerable long-filename lookup path, including same-hash collisions that drive execution into the TYPE_EXTEND branch. The attacker then gets a vulnerable Linux system to mount or otherwise parse that exFAT filesystem, for example through removable media, a downloaded disk image, an attached virtual disk, or an automated file-ingestion workflow. When the kernel exFAT driver searches the crafted directory, it releases the buffer backing a directory entry and later reads through a stale pointer into that released buffer. Under favorable memory-reuse or reclaim conditions this can cause a kernel fault and system crash; with additional exploit development, memory corruption could potentially be shaped into broader kernel compromise, although unaided reliable exploitation has not been demonstrated in the provided disclosure.

How to fix it

Apply a Linux kernel update that includes the exFAT fix moving brelse(bh) until after the directory-entry pointer is no longer dereferenced. Because no exact fixed package versions were provided, use the relevant upstream stable kernel or vendor/distribution advisory for each deployed platform and upgrade to the first fixed kernel version or later. Reboot systems into the patched kernel and remove or disable older vulnerable kernels where feasible. As compensating controls until patching is complete, restrict mounting of untrusted exFAT media and disk images, disable desktop/server automount behavior where not required, avoid processing user-supplied filesystem images on privileged hosts, and perform risky media/image analysis inside isolated disposable VMs or sandboxes.

How to confirm the fix worked

Confirm that each system is running a kernel build that contains the exFAT lifetime fix for exfat_find_dir_entry(), not merely that an updated package is installed. Validate with vendor package metadata, kernel changelogs, or source/backport inspection showing the brelse(bh) call occurs after all uses of the directory-entry pointer in the affected branch. After reboot, verify the active kernel with standard OS commands such as uname -r and package-manager queries. Where safe and appropriate, test patched non-production systems by mounting or scanning a known proof-of-concept crafted exFAT image under kernel sanitizers or crash monitoring and confirming there is no KASAN use-after-free, oops, or panic in exfat_find_dir_entry(). Also verify mitigations by checking that automount policies and file-ingestion workflows do not automatically mount untrusted exFAT media or disk images.

Typical attack path

1. Create a malicious exFAT filesystem image with crafted long filename directory entries and hash-collision behavior that reaches the vulnerable TYPE_EXTEND path.
2. Deliver the image through a channel the target is likely to mount or parse, such as removable media, virtual disk attachment, archive/image upload, or automated media ingestion.
3. Trigger mounting, directory enumeration, indexing, antivirus scanning, backup processing, or another workflow that causes the Linux kernel exFAT driver to inspect the crafted directory.
4. Cause exfat_find_dir_entry() to release the buffer_head and then dereference a pointer into the released buffer.
5. Induce a kernel crash or instability; if a reliable exploit is developed, attempt to leverage memory corruption for elevated kernel-level execution.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and endpoint telemetry for crashes or warnings involving the exFAT driver. Focus on events that occurred shortly after removable media insertion, disk-image attachment, loop-device mounting, file-indexing, backup processing, antivirus scanning, or user-upload ingestion. Relevant log sources include dmesg output, journald, /var/log/kern.log, /var/log/messages, apport/ABRT reports, kdump/vmcore records, EDR kernel-crash telemetry, hypervisor console logs, and storage/media ingestion application logs. Look for KASAN use-after-free reports, general protection faults, page faults, oopses, or kernel panics with stack traces containing exfat_find_dir_entry(), exfat_get_dentry(), exfat_extract_uni_name(), or exFAT mount/enumeration activity. If a suspicious event is found, preserve the mounted image or removable media, associated loop-device or mount commands, user/session context, and a copy of the kernel crash dump. There are no known public threat actors or ransomware campaigns tied to this issue in the provided data, so detection should emphasize crash forensics and anomalous exFAT processing rather than known campaign infrastructure.

• BUG: KASAN: use-after-free in exfat_find_dir_entry
• use-after-free in exfat_find_dir_entry
• exfat_find_dir_entry+
• exfat_get_dentry
• exfat_extract_uni_name
• BUG: unable to handle page fault
• Oops: 0000
• RIP: 0010:exfat_find_dir_entry
• KASAN: use-after-free
• DEBUG_PAGEALLOC
• PAGE_POISONING
• exfat:
• type=exfat
• -t exfat
• mount.exfat
• mount.exfat-fuse

What your security team should do

• Prioritize patching systems that mount removable media, process disk images, support user uploads, run virtualization/forensic workflows, or use automount features.
• Inventory Linux assets with exFAT support enabled or exFAT utilities/workflows in use, including endpoints and specialized media-processing systems.
• Disable or restrict automatic mounting of removable media and untrusted filesystem images until patched.
• Route untrusted disk images and removable media through isolated sandbox environments rather than production hosts.
• Monitor kernel logs for exFAT-related crashes, KASAN reports, page faults, oopses, or panics referencing exfat_find_dir_entry().
• Treat unexpected crashes during exFAT mount, directory listing, indexing, backup, or AV scanning as potential exploitation attempts and preserve the triggering image/media for forensic analysis.
• Track distribution advisories for fixed kernel package versions, because vendor backports may fix the issue without changing to a visibly new upstream kernel line.