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

In the Linux kernel, the following vulnerability has been resolved:

exfat: fix potential use-after-free in exfatfinddirentry()

In exfatfinddirentry(), the bufferhead obtained from exfatgetdentry() is released with brelse(bh) before the fall-through TYPEEXTEND branch reads the directory entry through ep (which points into bh->bdata):

brelse(bh); if (entrytype == TYPEEXTEND) { ... len = exfatextractuniname(ep, entryuniname); ... }

After brelse() drops our reference, nothing guarantees that the underlying page backing bh->bdata remains valid for the subsequent exfatextractuniname() read. This is the same pattern fixed in commit fc961522ddbd ("exfat: Fix potential use after free in exfatloadupcasetable()").

Move brelse(bh) so it runs after ep is no longer dereferenced on each branch.

Confirmed on QEMU x8664 with CONFIGKASAN=y + CONFIGDEBUGPAGEALLOC=y + CONFIGPAGEPOISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPEEXTEND path). With a debug-only invalidatebdev() 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 exfatfinddirentry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI RIP: 0010:exfatfinddirentry+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.