extendfile panics on FAT I/O error mid-extend (bread failure of the FAT block hits a KKASSERT instead of returning the error)
| Field | Value |
|---|---|
| ID | DF-3094 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H |
| CWE | CWE-755 / CWE-617 |
| File | sys/vfs/msdosfs/msdosfs_fat.c |
| Lines | extendfile FAT update path |
| Area | vfs/msdosfs |
| Confidence | likely |
| Discovered | 2026-09-06 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vfs |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
extendfile()'s FAT-chain update path hits a KKASSERT when the FAT block read fails mid-extend (I/O error on the backing device) instead of propagating the bread error — a device-error-triggered kernel panic on INVARIANTS-style assertions; release kernels take the bp error path. Requires a failing backing device during a file extend (I/O error, media pull). Low; not guest-verified (needs fault injection). Fix: return the bread error instead of asserting.
Timeline
- 2026-09-06 Discovered during pass-2 audit of msdosfs_fat.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3094 · 8 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 327 B | ↓ raw | |
| VERDICT.md | — | 1.3 KB | ↓ raw | |
| env.txt | — | 248 B | view raw | |
| fix.diff | — | 174 B | view raw | |
| manifest.json | — | 586 B | view raw | |
| msdos_patch.py | — | 463 B | view raw | |
| run.log | — | 219 B | view raw | |
| verdict.json | — | 1.7 KB | view raw |
DF-3094 - extendfile panics on FAT I/O error mid-extend (KKASSERT instead of error return)
Severity Low | verdict: not_reproduced | impact: none
Reproduce
Sources in this directory; build with cc -O2 -o <bin> <src> -pthread on the guest.
See VERDICT.md for the full narrative and run.log for the decisive output.
DF-3094 verification
Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
The claimed panic path is not reachable by geometry crafting on this guest, and the current code propagates FAT read errors correctly: (a) crafting BPB sectors-per-FAT=32767 on an 8MB image is rejected at mount (mount_msdos: Invalid argument - geometry validated); (b) with the mount-accepted original geometry, 300x64KB extending writes complete cleanly; (c) the cited chain in the current tree returns the bread error (fatentry, msdosfs_fat.c:495-498 returns after brelse on bread failure) and extendfile propagates fatentry errors. Demonstrating the claimed assert requires genuine device I/O failure (failing media) which the vn-backed rig cannot inject. Refuted as-written on this tree unless real I/O errors hit an assert elsewhere in the chain.
Kernel references
Fix
See fix.diff.
Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.
Fix verification
not_testableConfirmed kernel references
Detail
Evidence (decisive lines)
VERDICT.md + run.log + sources
PoC changes
adjusted from finding sketch to guest syscall/layout reality
Verified recommended fix
No fix required for the cited site (bread errors already propagate); optional hardening: initialize bp = NULL before bread in fatentry and guard brelse(bp) for bp == NULL.
Verdict
The claimed panic path is not reachable by geometry crafting on this guest, and the current code propagates FAT read errors correctly: (a) crafting BPB sectors-per-FAT=32767 on an 8MB image is rejected at mount (mount_msdos: Invalid argument - geometry validated); (b) with the mount-accepted original geometry, 300x64KB extending writes complete cleanly; (c) the cited chain in the current tree returns the bread error (fatentry, msdosfs_fat.c:495-498 returns after brelse on bread failure) and extendfile propagates fatentry errors. Demonstrating the claimed assert requires genuine device I/O failure (failing media) which the vn-backed rig cannot inject. Refuted as-written on this tree unless real I/O errors hit an assert elsewhere in the chain.
No comments yet.