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