hammer_install_volume dereferences the volume header after brelse(bp) — buffer-cache use-after-release read of vol0_stat_bigblocks into f_blocks
| Field | Value |
|---|---|
| ID | DF-3041 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-416 / CWE-362 |
| File | sys/vfs/hammer/hammer_ondisk.c |
| Lines | 250-257 |
| Area | vfs/hammer |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | memcorrupt |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
In the root-volume special case, hammer_install_volume releases the header buffer (brelse at :251, bp=NULL at :252) and then reads ondisk->vol0_stat_bigblocks twice (:254, :257) through the stale pointer captured at :183. After brelse the bp is owned by the buffer cache: a concurrent raw-device access to the same devvp or buffer-cache pressure can recycle/reuse the bp between the release and the two loads, so the kernel reads freed-or-reassigned buffer-cache memory and adds it (×512) into f_blocks/mnt_vstat.f_blocks. Impact is a racy stale kernel read whose value only corrupts statfs accounting (attacker-groomable bp content could inflate f_blocks, breaking quota/df arithmetic). Not built (below Phase V threshold — static proof code-evident). Fix: move the two f_blocks updates above the brelse (row diff).
Timeline
- 2026-09-02 Discovered during pass-2 audit of hammer_ondisk.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3041 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 281 B | ↓ raw | |
| VERDICT.md | — | 1.1 KB | ↓ raw | |
| env.txt | — | 248 B | view raw | |
| fix.diff | — | 103 B | view raw | |
| manifest.json | — | 582 B | view raw | |
| run.log | — | 145 B | view raw | |
| verdict.json | — | 1.3 KB | view raw |
DF-3041 - hammer_install_volume dereferences volume header after brelse(bp)
Severity Low | verdict: not_reproduced | impact: none
Reproduce
No runnable PoC on this rig (see VERDICT.md for why).
See VERDICT.md for the full narrative and run.log for the decisive output.
DF-3041 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
Not reproduced (race window is the few instructions between brelse at hammer_ondisk.c:251 and the two vol0_stat_bigblocks loads at :254/:257; forcing buffer recycling exactly there requires concurrent raw-device I/O on the same devvp during a mount, and even then only statfs accounting bytes change). Line-verified: bp released and NULLed at :251-252, then ondisk->vol0_stat_bigblocks read twice through the stale pointer captured at :183, added (x512) into f_blocks. Fix is a two-line move.
Kernel references
- sys/vfs/hammer/hammer_ondisk.c:251
- sys/vfs/hammer/hammer_ondisk.c:254
- sys/vfs/hammer/hammer_ondisk.c:257
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
none
Verified recommended fix
diff --git a/sys/vfs/hammer/hammer_ondisk.c: move the two f_blocks updates above the brelse at :251.
Verdict
Not reproduced (race window is the few instructions between brelse at hammer_ondisk.c:251 and the two vol0_stat_bigblocks loads at :254/:257; forcing buffer recycling exactly there requires concurrent raw-device I/O on the same devvp during a mount, and even then only statfs accounting bytes change). Line-verified: bp released and NULLed at :251-252, then ondisk->vol0_stat_bigblocks read twice through the stale pointer captured at :183, added (x512) into f_blocks. Fix is a two-line move.
No comments yet.