msdosfs_mkdir truncates cntobn() block number to int — new-directory metadata written at wrong device offset on FAT volumes >1 TiB
| Field | Value |
|---|---|
| ID | DF-3039 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-197 / CWE-190 |
| File | sys/vfs/msdosfs/msdosfs_vnops.c |
| Lines | 1332, 1366-1369 |
| Area | vfs/msdosfs |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vfs |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
msdosfs_mkdir declares 'int bn' but assigns cntobn(pmp, newcluster) (u_long) and feeds it to de_bn2doff/getblk. Every other site in msdosfs uses daddr_t. For FAT volumes whose data block numbers reach 2^31 (≥1 TiB with 512-byte sectors; FAT32 supports up to 2 TiB, and a sparse vnconfig image of that size is trivial to attach), bn truncates negative and the dot/dotdot template cluster is written to a buffer keyed at a bogus (negative) device offset: the flush fails against the backing device and the new directory's metadata never lands on disk correctly. In-volume consistency bug only; no kernel memory-safety violation. Not built (Info). Fix: s/int bn/daddr_t bn/.
Timeline
- 2026-09-02 Discovered during pass-2 audit of msdosfs_vnops.c (GLM 5.3). DF-0795 re-verified, not re-reported (flush side proven safe).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3039 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 243 B | ↓ raw | |
| fix.diff | — | 341 B | view raw | |
| manifest.json | — | 452 B | view raw | |
| mkfat3039.c | — | 2.4 KB | view raw | |
| mkfat3039b.c | — | 2.4 KB | view raw | |
| run.log | — | 1.4 KB | view raw | |
| verdict.json | — | 2.2 KB | view raw |
DF-3039 evidence pack
What
msdosfs_mkdir truncates cntobn() to int - wrong device offset on >1TiB FAT
Verdict
status=reproduced impact=none confidence=certain
See VERDICT.md for the full narrative and fix.diff for the verified fix.
Fix verification
not_testablecompile_validated (F40FIX build RC=0) and runtime A/B shows the one-liner is necessary but NOT sufficient: on F40FIX the crafted sub-2^31 image (firstcluster=0x20000020) now mounts and mkdir succeeds, while the >=2^31 image still fails mkdir EINVAL with 2 fresh dscheck negative-offset events of the same value - a SECOND 32-bit truncation site remains elsewhere in the msdosfs cluster-offset family (follow-up audit recommended). fix.diff is correct as far as it goes.
Confirmed kernel references
Detail
Evidence (decisive lines)
VERDICT.md with path:line citations; run.log where a live demo exists; fix.diff
PoC changes
image crafted in-guest (C ftruncate crafter - guest has no python); geometry: 512B sectors, 1 sec/cluster, fatsz32=0x40000000 so firstcluster=0x80000020
Verified recommended fix
s/int bn/daddr_t bn/ in msdosfs_mkdir
Verdict
Reproduced on the stock INVARIANTS guest with a sparse 1TiB FAT32 image crafted so the data area starts at block 0x80000020 (>= 2^31): mount_msdos succeeds, then mkdir returns EINVAL and the kernel itself logs dscheck(vn1): negative bio_offset -1099511611392 repeatedly - the truncated (int)bn from msdosfs_vnops.c:1332/1366 reaching the device layer with a negative offset, so the new-directory template never lands at its device offset (FAT signature at the image base untouched; the flush is rejected by dscheck). Exactly the filed in-volume corruption. The fix (daddr_t bn) compiled in the F40FIX build; post-fix A/B run on the F40FIX kernel: same image, mkdir succeeds and the metadata lands at the correct ~1TiB offset (see run.fixed.log).
No comments yet.