DF-0001 — PoC: reachable KASSERT panic in kern_truncate()/kern_ftruncate()

kern_truncate() / kern_ftruncate() unconditionally KASSERT that VOP_GETATTR succeeded whenever vfs_quota_enabled is on (sys/kern/vfs_syscalls.c:4036-4042 and :4111-4117). On an INVARIANTS kernel, any VOP_GETATTR failure on the target vnode panics the kernel — reachable from any local user with write access to the file via truncate(2) / ftruncate(2), no privilege required. CWE-617 reachable assertion. Severity Low (local DoS only; no memory corruption).

Verdict

REPRODUCED — deterministic panic: kern_ftruncate(): VOP_GETATTR didn't return 0 at kern_ftruncate+0x152, confirmed across two runs including one from a fresh vm.sh reset. See VERDICT.md for the full mechanism and panic.txt / run.log for the evidence.

Preconditions (all three are required)

1. options INVARIANTS kernel. The audited guest's X86_64_GENERIC kernel does ship INVARIANTS — verified by the presence of both panic strings in /boot/kernel/kernel. On a non-INVARIANTS kernel the KASSERT is a compiled-out no-op and nothing happens.
2. vfs.quota_enabled=1. The sysctl is CTLFLAG_RD, so it is a boot loader tunable (/boot/loader.conf: vfs.quota_enabled="1") and requires a reboot. Default is 0.
3. A filesystem whose VOP_GETATTR returns a nonzero error. Local hammer2/UFS GETATTR is effectively infallible. The realistic case is NFS returning ESTALE for GETATTR on a stale open-fd filehandle (the clean trigger; see below). Note: a merely-dead NFS server does NOT trip the bug on master — the client's attribute cache serves cached/local attrs with error=0, so the KASSERT never sees a failure. An application-level GETATTR error (ESTALE) is required.

Build

./build.sh        # ships sources to the guest and cc's them as user maxx

Or manually on the guest:

cc -O0 -g -o estale_trig estale_trig.c
cc -O0 -g -o trunc_panic trunc_panic.c
cc -O0 -g -o trunc_only  trunc_only.c

Run (full choreography)

./run.sh          # enables quota+reboots, stands up loopback NFS, triggers panic

run.sh does, end to end:

1. verifies the running kernel has the live KASSERT (INVARIANTS on);
2. sets vfs.quota_enabled="1" in /boot/loader.conf and reboots (non-reverting vm.sh down && vm.sh up);
3. stands up a loopback NFS server (rpcbind/mountd/nfsd) exporting /export, and NFS-mounts it soft, UDP, attribute-cache disabled (mount_nfs -U -s -x 1 -t 1 -o acregmin=0,acregmax=0,...);
4. as the unprivileged user (maxx, uid 1001, not in wheel), opens /mnt/estale_target, holding a fixed filehandle on the fd;
5. invalidates that filehandle server-side (rm + touch → new inode, client fd now references a stale handle, server still UP);
6. the process wakes and calls ftruncate(fd, 0) → kern_ftruncate → VOP_GETATTR_FP → GETATTR RPC on the stale handle → server returns NFSERR_STALE → nfs_getattr returns ESTALE → KASSERT(error==0) at vfs_syscalls.c:4113 → panic.

Expected output (bug present)

panic: kern_ftruncate(): VOP_GETATTR didn't return 0
kern_ftruncate() at kern_ftruncate+0x152
...
Debugger("panic")
db>

The guest halts in DDB; ssh dies. Recover with dfbsd-qemu/vm.sh reset.

Expected output (bug absent — non-INVARIANTS kernel)

The KASSERT compiles to a no-op; truncate(2)/ftruncate(2) simply return the GETATTR error (ESTALE/EIO). No memory-safety impact — which is why this is rated Low.

Files

DF-0001 — Verdict

Verdict: REPRODUCED (deterministic kernel panic, confirmed across two independent runs including one from a fresh vm.sh reset).

Impact: local denial-of-service (kernel panic) on INVARIANTS+quota hosts; no memory corruption, no privilege escalation. Rated Low by the finding — confirmed.

What the bug is

kern_truncate() and kern_ftruncate() (both reachable from any local user with write permission to a file via truncate(2)/ftruncate(2)) call VOP_GETATTR/VOP_GETATTR_FP to read the file's uid/gid/size for quota accounting, and unconditionally KASSERT that the call succeeded:

• sys/kern/vfs_syscalls.c:4036-4042 — kern_truncate: c if (vfs_quota_enabled) { error = VOP_GETATTR(vp, &vattr); KASSERT(error == 0, ("kern_truncate(): VOP_GETATTR didn't return 0")); /* :4038 */ ... }
• sys/kern/vfs_syscalls.c:4111-4117 — kern_ftruncate: c if (vfs_quota_enabled) { error = VOP_GETATTR_FP(vp, &vattr, fp); KASSERT(error == 0, ("kern_ftruncate(): VOP_GETATTR didn't return 0")); /* :4113 */ ... }

KASSERT is panic under options INVARIANTS and a no-op otherwise (sys/sys/systm.h:94-117). The block is gated only by the global vfs_quota_enabled (a boot loader tunable, sys/kern/vfs_quota.c:112-115, CTLFLAG_RD so settable only at boot), not by any per-mount or can-the-FS-actually-fail-GETATTR check. VOP_GETATTR is not guaranteed to succeed: any filesystem whose vop_getattr can return a nonzero error post-lookup/lock trips it. There is no privilege check before the KASSERT.

Precondition check on the tested guest (master DEV, X86_64_GENERIC)

The guest's X86_64_GENERIC kernel does ship INVARIANTS, so the KASSERT is a live panic() — contrary to the common assumption that production GENERIC kernels leave INVARIANTS off. This is what makes the bug fire on this exact kernel.

How the panic was triggered (the ESTALE path)

The finding's narrative names two GETATTR-failure modes: an NFS transient (ESTALE/EIO) and a forced-reclaim vnode. Empirically, on DragonFly master:

• Dead-server (transport-failure) does NOT reach the KASSERT. When the NFS server is killed, the client logs nfs server ... not responding / nfs send error 61 (ECONNREFUSED) and nfs_getattr() (sys/vfs/nfs/nfs_vnops.c:685-738) returns cached/local attributes with error=0 rather than propagating the transport error (the attribute cache at sys/vfs/nfs/nfs_subs.c:885-933 serves the GETATTR, and for a client-written file the NLMODIFIED local-attr path makes the hit sticky). So truncate()/ftruncate() propagate the error only from the later VOP_SETATTR RPC (as EINTR/EIO), and the KASSERT — which sits on GETATTR, before SETATTR — never sees a nonzero value. The most obvious "kill the NFS server" scenario does not trip this bug on master.
• A genuine application-level GETATTR error DOES reach the KASSERT. The clean way to force nfs_getattr() to return a nonzero error is ESTALE: the client holds an open fd (fixed vnode/filehandle), the server deletes and recreates the file (new inode → old filehandle is now stale), and the server — still up and responding — returns NFSERR_STALE for the GETATTR RPC on the stale handle. nfsm_request + the NEGKEEPOUT/ ERROROUT macros (sys/vfs/nfs/nfsm_subs.h:109-124) propagate that error out of nfs_getattr() (return (error) at nfs_vnops.c:737), so VOP_GETATTR_FP returns ESTALE to kern_ftruncate, and the KASSERT at vfs_syscalls.c:4113 fires.

Trigger choreography (see run.sh)

1. Boot vfs.quota_enabled=1 (loader tunable, reboot).
2. Stand up a loopback NFS server (rpcbind/mountd/nfsd) exporting /export; NFS-mount it soft, UDP, attribute-cache disabled (mount_nfs -U -s -x 1 -t 1 -o acregmin=0,acregmax=0,...).
3. As the unprivileged user maxx (uid 1001, not in wheel), open() /mnt/estale_target → fd holds a fixed vnode/filehandle; sleep.
4. Server-side: rm /export/estale_target && touch /export/estale_target (new inode; the client fd's handle is now stale; server still UP).
5. The process wakes and calls ftruncate(fd, 0): kern_ftruncate → VOP_GETATTR_FP → NFS GETATTR RPC on the stale filehandle → server returns NFSERR_STALE → nfs_getattr returns ESTALE → KASSERT(error == 0, ...) at vfs_syscalls.c:4113 → panic.

Decisive evidence

Serial-console panic signature (dfbsd-qemu/boot.log), identical across the initial run and the fresh-vm.sh reset confirmation run:

panic: kern_ftruncate(): VOP_GETATTR didn't return 0
cpuid = 0
Trace beginning at frame 0xfffff800abb23798
kern_ftruncate() at kern_ftruncate+0x152 0xffffffff80705532
kern_ftruncate() at kern_ftruncate+0x152 0xffffffff80705532
sys_xsyscall() at sys_xsyscall+0x89 0xffffffff80bd6749
syscall2() at syscall2+0x11e 0xffffffff80bd611e
Debugger("panic")
Stopped at Debugger+0x7c: movb $0,0xbd77f9(%rip)
db>

The panic names exactly the function the finding cites (kern_ftruncate, KASSERT at :4113 → +0x152 in the disassembly), reached via the normal syscall2 → sys_xsyscall → kern_ftruncate path from an unprivileged ftruncate(2). The kern_truncate twin at :4038 is the same bug; the ftruncate variant was used for the demonstration only because the ESTALE choreography is cleanest on an open fd. (trunc_panic.c / trunc_only.c are retained as the path-truncate variants and the local-FS/no-panic baselines.)

Exploit chain

None — this is not a memory-corruption class. It is a reachable assertion (CWE-617): the primitive is a kernel panic() (DoS), full stop. No bytes are corrupted, no pointers are hijacked, no privilege changes. The realistic impact ceiling is denial of service of an INVARIANTS+quota host by any local user with write access to a file on a GETATTR-failing (NFS) mount. No further primitive is derivable.

PoC changes made during verification

• Added estale_trig.c — the trigger that actually fires the panic. The original trunc_panic.c (path-based truncate against a "failing GETATTR FS") does not fire on master because, as traced above, a transport GETATTR failure is papered over by the NFS attribute cache; only an application-level GETATTR error (ESTALE on a stale open-fd handle) reaches the KASSERT. estale_trig.c implements that choreography.
• Added trunc_only.c — errno-printing diagnostic that proved (via the EINTR-from-SETATTR result) that the dead-server path returns GETATTR=0 and therefore cannot trip the KASSERT. Kept as the negative evidence / baseline.
• Sharpened trunc_panic.c to print errnos and populate the target.
• Added run.sh — the multi-step reproducer (quota reboot + loopback NFS + ESTALE handle invalidation), since the bug needs three runtime preconditions the clean-install guest lacks. build.sh builds all three sources as the unprivileged user.

Recommended fix

Convert both KASSERTs to proper error-returns (the done: labels already perform the correct cleanup: vput(vp) for kern_truncate at :4051, fdrop(fp) for kern_ftruncate at :4128; kern_ftruncate must vn_unlock(vp) first because its done: sits after the vn_unlock at :4126). The standalone git apply-able diff is fix.diff; it applies cleanly to sys/kern/vfs_syscalls.c. This matches the finding markdown's ## Recommended fix proposal (same error-return + cleanup shape); the runner's diff additionally carries an explicit vn_unlock(vp) before the goto done in kern_ftruncate to avoid leaking the vnode lock.

Fix validation (Phase 8 — built + booted a single-fix kernel)

fix_status: fixed — clean before/after on the same guest.

Baseline (unpatched #0)

• kern.version: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026
• KASSERT panic strings present in /boot/kernel/kernel (verified: both kern_truncate(): VOP_GETATTR didn't return 0 and kern_ftruncate(): VOP_GETATTR didn't return 0).
• Ran run.sh end-to-end (loader tunable vfs.quota_enabled=1 + reboot + loopback NFS export + ESTALE handle invalidation + ftruncate(2)): PANIC — guest halted in DDB. Serial-console signature (baseline_panic.txt): panic: kern_ftruncate(): VOP_GETATTR didn't return 0 cpuid = 1 Trace beginning at frame 0xfffff801185a3798 kern_ftruncate() at kern_ftruncate+0x152 0xffffffff80705e22 kern_ftruncate() at kern_ftruncate+0x152 0xffffffff80705e22 sys_xsyscall() at sys_xsyscall+0x89 0xffffffff80bd7039 syscall2() at syscall2+0x11e 0xffffffff80bd6a0e Debugger("panic") Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip) db>

Patched (single-fix #1)

• kern.version: DragonFly 6.5-DEVELOPMENT #1: Thu Jul 2 17:15:30 UTC 2026
• sha256 /boot/kernel/kernel: f30fe81d658b01e8fcf2469190aae82f0c5b67961c112da2314f5bece9999902
• Build: make -j6 nativekernel KERNCONF=X86_64_GENERIC from /usr/src with fix.diff applied (vfs_syscalls.o recompiled, kernel.debug re-linked, kernel.stripped produced, rc=0). Full output: fix_build.log (35393 lines). Build time ≈ 6 min on warm obj.
• KASSERT panic strings ABSENT from /boot/kernel/kernel post-build (verified: strings /boot/kernel/kernel | grep "VOP_GETATTR did" returns nothing — the assertion was successfully removed).
• Ran the same ESTALE choreography (run_fix_validate.sh) — twice for determinism:
• NO PANIC. kern_ftruncate now propagates the GETATTR error to the caller instead of asserting. Trigger output: estale_trig: DIAG fstat (VOP_GETATTR) returned error: errno: Stale NFS file handle estale_trig: FTRUNCATE returned error (...): errno: Stale NFS file handle (Both lines are reached — on the unpatched kernel, the ftruncate line was never reached because the KASSERT fired first.)
• Guest stays UP after the trigger; boot.log contains no panic: / Stopped at / db> line.

Verdict

The fix converts a kernel panic() (CWE-617 reachable assertion, local DoS on INVARIANTS+quota hosts) into a clean error-return: truncate(2) / ftruncate(2) now return the underlying VOP_GETATTR error (ESTALE for the NFS stale-handle case, EIO for transport failures, etc.) to the caller, matching the documented syscall contract. Before/after is deterministic across two independent runs on the patched kernel.