fattime2timespec accepts out-of-range month (0, 13-15) and hour>23/minute>59 fields from crafted FAT images — no bounds validation (garbage dates, index safely masked)
| Field | Value |
|---|---|
| ID | DF-2957 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N |
| CWE | CWE-20 |
| File | sys/kern/subr_fattime.c |
| Lines | 226-239 |
| Area | kern/msdosfs |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
Unlike the day field (DF-0199), the month field is never range-checked: crafted dd with month 0 or 13-15 indexes daytab entries 0/14/15 via the safely-masked (dd>>5)&0x3f, landing the date in January of the cycle — month 0 with year 127 decodes as 2104-01-15 (interacting with the DF-2955 wrap); month 13/15 similarly alias into January. Likewise hh up to 31 and mm up to 63 produce times up to 31.5h that spill into the following day (verified on guest harness: dd=0x0021 dt=0xffff dh=0xff → 1980-01-02 08:04:04.55). No OOB is possible (mask + table geometry proven); tv_nsec stays canonical. Same wrong-mtime impact class as DF-0199 — a maintainer fixing DF-0199 should clamp all fields at the msdosfs parse boundary (row diff). Harness output in the DF-2955 pack; Phase V skipped per Low/Info rule.
Timeline
- 2026-09-02 Discovered during pass-2 audit of subr_fattime.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2957 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 758 B | ↓ raw | |
| VERDICT.md | — | 1.2 KB | ↓ raw | |
| build.sh | — | 50 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 1.3 KB | view raw | |
| h41.c | — | 14.9 KB | view raw | |
| harness.log | — | 2.0 KB | view raw | |
| manifest.json | — | 542 B | view raw | |
| run.sh | — | 105 B | view raw | |
| verdict.json | — | 2.4 KB | view raw |
DF-2957 — fattime out-of-range month/hour/minute (Info-tier hardening verification)
What
fattime out-of-range month/hour/minute
Build
cd /root/h41 && make
Run
kldload ./h41.ko; sysctl -w debug.h41.cmd=10
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
A/B one-liner: baseline: garbage month/hour decodes | fix: clamped
Files
README.md VERDICT.md build.sh env.txt fix.diff h41.c harness.log manifest.json run.sh verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2957 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Mechanically reproduced via the harness on the stock guest by calling the exported fattime2timespec with crafted FAT fields: (1) month nibble 0 with year 127 decoded to tv_sec=4229884768 = 2104-01-15 - the out-of-range month aliases into January of the leap cycle (daytab[(dd>>5)&0x3f] entry 0) exactly as filed; (2) month nibble 13 decoded to a January-of-cycle date as well; (3) hour field 31 + minute 63 decoded to a time 32.05h past midnight spilling into the following day (1980-01-02 08:03 for a 1980-01-01 entry). No OOB is possible (the 6-bit index is safely masked into the 64-entry table; geometry re-verified), tv_nsec stays canonical - garbage mtime class only, same family as DF-0199. On the fix kernel all fields clamp (hh=23/mm=59/ss<=59, month to [1,12]: the hh31/mm63 case returned exactly 23:59:00 same-day). NOTE: the clamped month-0/year-127 sample lands at day > 49710 where the separately-filed DF-2955 32-bit DAY*day wrap applies - the printed value there is compounded by that known bug, not a clamp failure.
Baseline vs fix kernel
baseline: baseline: garbage month/hour decodes | fix: clamped fix: behavior changed as designed (see verdict)
Fix verification
fixedA/B: baseline garbage month/hour decodes; fix kernel clamped decodes (exact 23:59:00 for the 31:63 case).
Confirmed kernel references
Detail
Evidence (decisive lines)
harness.log T10: three crafted-field decodes; fix kernel T10: hh31/mm63 -> exactly 23:59:00 (clamp proof)
PoC changes
crafted dd/dt/dh values driven directly into the exported kernel function
Verified recommended fix
Clamp month to [1,12] and hh/mm/ss to their ranges when unpacking
Verdict
Mechanically reproduced via the harness on the stock guest by calling the exported fattime2timespec with crafted FAT fields: (1) month nibble 0 with year 127 decoded to tv_sec=4229884768 = 2104-01-15 - the out-of-range month aliases into January of the leap cycle (daytab[(dd>>5)&0x3f] entry 0) exactly as filed; (2) month nibble 13 decoded to a January-of-cycle date as well; (3) hour field 31 + minute 63 decoded to a time 32.05h past midnight spilling into the following day (1980-01-02 08:03 for a 1980-01-01 entry). No OOB is possible (the 6-bit index is safely masked into the 64-entry table; geometry re-verified), tv_nsec stays canonical - garbage mtime class only, same family as DF-0199. On the fix kernel all fields clamp (hh=23/mm=59/ss<=59, month to [1,12]: the hh31/mm63 case returned exactly 23:59:00 same-day). NOTE: the clamped month-0/year-127 sample lands at day > 49710 where the separately-filed DF-2955 32-bit DAY*day wrap applies - the printed value there is compounded by that known bug, not a clamp failure.
No comments yet.