CVE-2026-63808

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.