Skip to main content
VulnerabilityPublished Updated

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

Affects Linux kernelSource CVE Database V5

0

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:30 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.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

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

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…