Skip to main content
VulnerabilityPublished Updated

CVE-2026-63808: Linux kernel · exfat: fix potential use-after-free in exfat_find_dir_entry()

Source GCVE Database

0
Authoritative record:CVE-2026-63808· Critical 9.8

Not known to be exploited · CVSS 9.8 Critical · fixed in e48f413c2815787b8cade2795e194e3c4cd782ef : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 44% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in e48f413c2815787b8cade2795e194e3c4cd782ef, e6f1a11cfb808441a43ffae9b476cc135732cd27, adfacfbaeae2cb760f492357cc36b41f84ef7f86 +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < e48f413c2815787b8cade2795e194e3c4cd782ef
Fixed in
  • e48f413c2815787b8cade2795e194e3c4cd782ef
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < e6f1a11cfb808441a43ffae9b476cc135732cd27
Fixed in
  • e6f1a11cfb808441a43ffae9b476cc135732cd27
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < adfacfbaeae2cb760f492357cc36b41f84ef7f86
Fixed in
  • adfacfbaeae2cb760f492357cc36b41f84ef7f86
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < 708b97e792945d3e4653939fd3405d71a61ad065
Fixed in
  • 708b97e792945d3e4653939fd3405d71a61ad065
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < 8e0abc17fbd7e305802e84fe98b4950d50f9c433
Fixed in
  • 8e0abc17fbd7e305802e84fe98b4950d50f9c433
LinuxLinuxAffected
  • ≥ ca06197382bde0a3bc20215595d1c9ce20c6e341, < 06c4e1e9967d332ac33ba38b7819851089ff9359
Fixed in
  • 06c4e1e9967d332ac33ba38b7819851089ff9359

AI-suggested

A fix for this vulnerability has been applied to the Linux kernel source code. Users and administrators should update their Linux kernel to a version that includes this patch to eliminate the use-after-free condition in exfat_find_dir_entry(). Patch status is confirmed by the description of the fix; no additional mitigation is required beyond applying the official kernel update.

Description

In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): brelse(bh); if (entry_type == TYPE_EXTEND) { ... len = exfat_extract_uni_name(ep, entry_uniname); ... } After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd ("exfat: Fix potential use after free in exfat_load_upcase_table()"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.

References

Community reviews

Loading reviews…