Answer in brief
CVE-2026-63808 records a Unknown severity vulnerability in exfat: fix potential use-after-free in exfat_find_dir_entry(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-63808 records a Unknown severity vulnerability in exfat: fix potential use-after-free in exfat_find_dir_entry(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <e6f1a11cfb808441a43ffae9b476cc135732cd27 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <e48f413c2815787b8cade2795e194e3c4cd782ef || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <06c4e1e9967d332ac33ba38b7819851089ff9359 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <8e0abc17fbd7e305802e84fe98b4950d50f9c433 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <4d101016d5e587f820b3ae2d5bb6770d86342649 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <adfacfbaeae2cb760f492357cc36b41f84ef7f86 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <708b97e792945d3e4653939fd3405d71a61ad065 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <3f5f8ee9917cc2b9076ac533492d8a200edcabb8 | e6f1a11cfb808441a43ffae9b476cc135732cd27, e48f413c2815787b8cade2795e194e3c4cd782ef, 06c4e1e9967d332ac33ba38b7819851089ff9359, 8e0abc17fbd7e305802e84fe98b4950d50f9c433, 4d101016d5e587f820b3ae2d5bb6770d86342649, adfacfbaeae2cb760f492357cc36b41f84ef7f86, 708b97e792945d3e4653939fd3405d71a61ad065, 3f5f8ee9917cc2b9076ac533492d8a200edcabb8 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <e6f1a11cfb808441a43ffae9b476cc135732cd27 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <e48f413c2815787b8cade2795e194e3c4cd782ef || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <06c4e1e9967d332ac33ba38b7819851089ff9359 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <8e0abc17fbd7e305802e84fe98b4950d50f9c433 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <4d101016d5e587f820b3ae2d5bb6770d86342649 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <adfacfbaeae2cb760f492357cc36b41f84ef7f86 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <708b97e792945d3e4653939fd3405d71a61ad065 || >=ca06197382bde0a3bc20215595d1c9ce20c6e341 <3f5f8ee9917cc2b9076ac533492d8a200edcabb8 | e6f1a11cfb808441a43ffae9b476cc135732cd27, e48f413c2815787b8cade2795e194e3c4cd782ef, 06c4e1e9967d332ac33ba38b7819851089ff9359, 8e0abc17fbd7e305802e84fe98b4950d50f9c433, 4d101016d5e587f820b3ae2d5bb6770d86342649, adfacfbaeae2cb760f492357cc36b41f84ef7f86, 708b97e792945d3e4653939fd3405d71a61ad065, 3f5f8ee9917cc2b9076ac533492d8a200edcabb8 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.