DF-3039
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).
No comments yet.