Unconditional nlinks decrement on unlink wraps a crafted nlinks=0 inode to UINT64_MAX — KKASSERT((int64_t)nlinks >= 0) panic in hammer_sync_inode (INVARIANTS) / poisoned link count persisted to media
| Field | Value |
|---|---|
| ID | DF-3004 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H |
| CWE | CWE-191 |
| File | sys/vfs/hammer/hammer_inode.c |
| Lines | 2980 (decrement: hammer_object.c:854; load :525) |
| Area | vfs/hammer |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vfs |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
hammer_ip_del_direntry() decrements ip->ino_data.nlinks unconditionally. The kernel never cross-checks the on-disk inode record's nlinks against the number of directory entries referencing it, so a crafted image pairing a direntry with an inode record whose nlinks field is 0 drives nlinks to 0xFFFFFFFFFFFFFFFF on unlink. The backend then asserts KKASSERT((int64_t)nlinks >= 0) at :2980 — guaranteed panic on INVARIANTS kernels from merely unlinking a file on mounted attacker-supplied media; on production kernels the wrapped value is synced to disk, leaving a permanently 'linked' undeletable inode (metadata poisoning). Low: crafted-image precondition, panic/consistency-only, and the assert is doing its intended job as a consistency tripwire. Fix: clamp/guard the decrement (if nlinks > 0 else EINVAL/force-DELETING) and/or validate nlinks != 0 at hammer_get_inode load.
Timeline
- 2026-09-02 Discovered during pass-2 audit of hammer_inode.c (GLM 5.3). DF-0770/0771 re-verified, not re-reported.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3004 · 12 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 741 B | ↓ raw | |
| VERDICT.md | — | 2.3 KB | ↓ raw | |
| build.sh | — | 112 B | view raw | |
| df3004b.c | — | 738 B | view raw | |
| df3004b_run.log | — | 154 B | view raw | |
| env.txt | — | 401 B | view raw | |
| fix.diff | — | 435 B | view raw | |
| fix_run.log | — | 181 B | view raw | |
| h1patch2.py | — | 6.1 KB | view raw | |
| manifest.json | — | 719 B | view raw | |
| run.sh | — | 127 B | view raw | |
| verdict.json | — | 2.7 KB | view raw |
DF-3004 PoC evidence pack
What
Unconditional nlinks decrement wraps a crafted nlinks=0 inode to UINT64_MAX (userspace-visible).
Build
guest: newfs_hammer -f 12G image; host: python3 h1patch2.py IMG 3004 file_3004
Run
vnconfig; mount_hammer; ./df3004b /mnt/h1t/d/file_3004; sync; umount
Expected
fstat: nlink 0 before unlink -> 4294967295 after (UINT64_MAX wrap); no panic in canonical case
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 All logs are full untrimmed captures unless noted. fix.diff is the git-apply-able verified fix (authored after verification; never applied to the audit tree).
DF-3004 - verification verdict
Status: reproduced | reproduced: 1 | impact: corruption | confidence: likely
Wrap reproduced and observable; the sync-panic sub-claim did NOT manifest in the canonical crafted case. Offline patch set the INODE records on-disk nlinks (hammer_inode_data+72) to 0 while the direntry still referenced it (CRC32C-verified matching, leaf data CRC + node CRC recomputed). On mount, stat exposed nlink=0 (no load-time validation); unlink decremented unconditionally (hammer_object.c:854) and fstat on a held fd showed nlink=4294967295 - the kernel-side UINT64_MAX wrap, userspace-visible, exactly the poisoned link count. However sync/synctid/umount completed WITHOUT the hammer_sync_inode KKASSERT((int64_t)nlinks >= 0) (hammer_inode.c:2980): analysis of the flush code shows the deleted-direntry dependency adjustment (++nlinks) re-wraps the count back to 0 before the assert comparison (sync_ino_data.nlinks == nlinks == 0), so the single-direntry crafted case does not panic; the assert would fire only for cross-flush-group record mixes. The 0-nlinks load and the unconditional wrap are the reproduced core. Fix (guarded decrement + underflow report) A/B validated on the fix-all kernel.
Evidence pointers
df3004b_run.log: before unlink nlink=0; after unlink nlink=4294967295; after 3s flush pause nlink=4294967295; no panic; umount-ok
Kernel references
PoC changes vs the filing sketch
panic sub-claim refuted for the canonical case with mechanism analysis; open-fd fstat used to observe the wrap
Fix
recommendation: guard the decrement + validate nlinks != 0 at hammer_get_inode load
fix status: fixed
A/B on fix-all kernel: same crafted image, fstat after unlink shows nlink=0 (no wrap) + underflow report
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
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
fixedA/B on fix kernel #2: same crafted image; after unlink nlink stays 0 (stock: 4294967295 wrap) and HAMMER: nlinks underflow on obj ... is reported; sync+umount clean.
Confirmed kernel references
Detail
Exploit chain
crafted image: inode nlinks=0 + live direntry -> mount (root) -> open+unlink -> unconditional decrement wraps to UINT64_MAX -> fstat shows 4294967295 (userspace-visible poisoned link count)
Evidence (decisive lines)
df3004b_run.log: before unlink nlink=0; after unlink nlink=4294967295; after 3s flush pause nlink=4294967295; no panic; umount-ok
PoC changes
panic sub-claim refuted for the canonical case with mechanism analysis; open-fd fstat used to observe the wrap
Verified recommended fix
guard the decrement + validate nlinks != 0 at hammer_get_inode load
Verdict
Wrap reproduced and observable; the sync-panic sub-claim did NOT manifest in the canonical crafted case. Offline patch set the INODE records on-disk nlinks (hammer_inode_data+72) to 0 while the direntry still referenced it (CRC32C-verified matching, leaf data CRC + node CRC recomputed). On mount, stat exposed nlink=0 (no load-time validation); unlink decremented unconditionally (hammer_object.c:854) and fstat on a held fd showed nlink=4294967295 - the kernel-side UINT64_MAX wrap, userspace-visible, exactly the poisoned link count. However sync/synctid/umount completed WITHOUT the hammer_sync_inode KKASSERT((int64_t)nlinks >= 0) (hammer_inode.c:2980): analysis of the flush code shows the deleted-direntry dependency adjustment (++nlinks) re-wraps the count back to 0 before the assert comparison (sync_ino_data.nlinks == nlinks == 0), so the single-direntry crafted case does not panic; the assert would fire only for cross-flush-group record mixes. The 0-nlinks load and the unconditional wrap are the reproduced core. Fix (guarded decrement + underflow report) A/B validated on the fix-all kernel.
No comments yet.