DF-0793 — async TRIM block-free UAF (verification)

Verdict: NOT REPRODUCED as filed (the async-TRIM code path is dead code on current master). Root cause discovered: ffs_blkfree's MNT_TRIM gate reads ip->i_devvp->v_mount (devfs mount, never has MNT_TRIM) instead of ip->i_vnode->v_mount (the ufs mount). A latent UAF exists and is un-masked by fixing that pointer; fix.diff fixes both the pointer and the missing drain. See VERDICT.md for the full analysis.

Files

Reproduce (on the DragonFly guest)

The async-TRIM path needs (a) a kernel that consults the right mount pointer (unpatched master does NOT — that is the bug) and (b) an async device (QEMU's vn/vbd complete FREEBLKS synchronously, so they cannot reproduce the in-flight window). asyncd.c supplies (b).

# as root on the guest (mount needs privilege; vfs.usermount=0):
./build.sh                       # builds asyncd.ko + trim_uaf
kldload ./asyncd.ko
newfs /dev/asyncd0s0
# trim_uaf mounts /dev/vn0 by default; point it at asyncd0s0:
cc -o trim_uaf_async trim_uaf.c -DDEV=\"/dev/asyncd0s0\"   # or sed
./trim_uaf_async 5
dmesg | grep -c 'asyncd: FREEBLKS'    # unpatched -> 0 (TRIM dead = the bug)

Fix validation

ssh dfbsd "cat > /root/fix.diff" < fix.diff
ssh dfbsd "cd /usr/src && patch -p1 < /root/fix.diff"
ssh dfbsd "cd /usr/src && make -j6 nativekernel KERNCONF=X86_64_GENERIC"
# install + reboot, then re-run the harness -> FREEBLKS now flows, no panic

DF-0793 — Use-after-free in async TRIM block-free path

Verdict (one line)

NOT REPRODUCED (false-positive as filed): the async-TRIM store/defer/UAF code path in ffs_blkfree is unreachable on current master, because its MNT_TRIM gate reads the wrong mount pointer. The finding's underlying concern (missing taskqueue_drain in ffs_unmount) is a real latent defect, but it is masked by a separate bug that makes the entire FFS async-TRIM feature non-functional. A fix for both was authored and validated.

1. The claim

ffs_blkfree (sys/vfs/ufs/ffs_alloc.c:1667-1697), when the mount has MNT_TRIM, kmallocs a struct ffs_blkfree_trim_params, stores raw, un-refcounted copies of ip->i_fs, ip->i_devvp, ip->i_dev, and submits a BUF_CMD_FREEBLKS bio whose completion callback (ffs_blkfree_trim_completed, :1646) defers the real free work (ffs_blkfree_trim_task :1633) onto taskqueue_swi. ffs_unmount (ffs_vfsops.c:824) frees fs/ump/devvp with no taskqueue_drain of the pending TRIM tasks anywhere in sys/vfs/ufs/. Alleged impact: delete a large file under an MNT_TRIM mount, then umount while TRIM bios are in-flight -> the deferred task dereferences freed M_UFSMNT heap / freed device vnode -> UAF.

The "no drain" half of the claim is factually correct: grep -rn taskqueue_drain sys/vfs/ufs/ returns nothing, and taskqueue_enqueue(taskqueue_swi,&tp->task) at ffs_alloc.c:1655 is the only swi reference in the whole UFS tree.

2. Why it does not reproduce — the gate uses the wrong mount pointer

ffs_blkfree decides whether to TRIM with:

struct mount *mp = ip->i_devvp->v_mount;          /* ffs_alloc.c:1670 */
...
if (!(mp->mnt_flag & MNT_TRIM)) {                 /* ffs_alloc.c:1673 */
        ffs_blkfree_cg(...);                       /* synchronous */
        return;
}
/* ... TRIM path: kmalloc tp, store raw ptrs, submit async FREEBLKS bio ... */

ip->i_devvp is the block-device vnode the filesystem lives on. Its v_mount is the devfs mount of /dev (or NULL), not the ufs mount. ffs_mountfs never sets devvp->v_mount; it sets dev->si_mountpoint = mp (ffs_vfsops.c:734) — a field on the cdev that ffs_blkfree does not consult. The real ufs mount is reachable from the inode as ip->i_vnode->v_mount.

So mp->mnt_flag & MNT_TRIM is evaluated against the devfs mount, which never has MNT_TRIM. The gate is therefore always TRUE (TRIM never selected), ffs_blkfree_cg runs synchronously, and the store/defer/UAF code at :1679-1697 is dead code.

Proof (kernel instrumentation)

A diagnostic kernel with a kprintf at the top of ffs_blkfree, on a ufs mount mounted with MNT_TRIM (mount | grep shows ufs, trim, local), printing for 48 ffs_blkfree calls:

devvp->v_mount      = 0xfffff8008db3c800      (devfs mount)
ip->i_vnode->v_mount= 0xfffff8008eddb800      (the ufs mount — DIFFERENT object)
devvp_vmtrim        = 0                       (devfs mount has NO MNT_TRIM)
ipvmount_trim       = 1                       (ufs mount HAS MNT_TRIM)

The flag is set on the ufs mount (ipvmount_trim=1) but never seen, because the check reads the device vnode's mount (devvp_vmtrim=0).

Behavioural proof (async-disk KLD)

To remove the "QEMU has no slow async TRIM device" excuse, a small root-loaded KLD (asyncd.c, modelled on sys/dev/disk/md/md.c) provides a 256 MB memory-backed disk whose READ/WRITE complete synchronously but whose BUF_CMD_FREEBLKS completion is deferred 2 s via a callout — exactly mimicking a real SSD. Mounting ufs+trim on it (via a direct mount(2) syscall, which the kernel accepts without a device-capability check — only the userland mount_ufs gates on kern.cam.da.*.trim_enabled, sbin/mount_ufs/mount_ufs.c:101) and deleting a file:

* see §4.

0 FREEBLKS on the unpatched kernel is the definitive confirmation that the TRIM branch is never taken: ffs_blkfree always returns through the synchronous ffs_blkfree_cg path. The struct ffs_blkfree_trim_params, the bio, the callback, and the swi task are never instantiated.

3. Reachability for an unprivileged user

Even setting aside the dead-code problem, the async-TRIM path is not reachable by an unprivileged user on the default guest:

• vfs.usermount = 0 — the user cannot call mount(2) at all.
• The only MNT_TRIM-accepting mount path (mount_ufs userland) restricts TRIM to CAM da disks with trim_enabled; the guest has no da disk (root is vbd0/hammer2). The kernel mount(2) would accept MNT_TRIM on any device, but issuing it still requires root.
• vn completes BUF_CMD_FREEBLKS as a synchronous no-op (sys/dev/disk/vn/vn.c:304), so even a root-mounted vn+trim would never produce an in-flight TRIM bio.

So: on the default GENERIC guest an unprivileged user has no path to the TRIM block-free path. There is no escalation surface to develop.

4. The latent UAF is real (demonstrated by un-masking it)

Fixing only the masking mount-pointer bug (mp = ip->i_vnode->v_mount) makes the TRIM path reachable — this is the "expose" kernel above, where 405 FREEBLKS bios flow and the deferred ffs_blkfree_trim_task dereferences the stored tp->i_fs/tp->i_devvp/tp->i_dev. That confirms the finding's mechanism is genuine (the store-then-defer pattern runs, and the deferred task does deref pointers that ffs_unmount will free).

No panic was observed on the expose kernel, because of an implicit synchronization: umount latency tracks the async bio delay exactly (2 s delay → 2129 ms umount; 4 s delay → 3931 ms umount). Something in the unmount path (the device buf drain on vinvalbuf(devvp,V_SAVE) / vrele(devvp)) waits for the in-flight FREEBLKS bios to biodone(), which lets the enqueued swi tasks run while fs is still valid. The residual UAF window — biodone (task enqueued) → umount unblocks → kfree(fs) → swi task finally runs — is real but very tight and did not fire in these runs. It would be widened under heavy load / a backlogged swi taskqueue. The missing taskqueue_drain is therefore a legitimate latent defect that should be closed.

5. The fix (fix.diff)

fix.diff (validated, git apply --check clean) makes two changes:

1. Correctness — consult the right mount (ffs_alloc.c:1670): mp = ip->i_vnode->v_mount; (was ip->i_devvp->v_mount). This is what actually enables FFS async TRIM; without it the feature is dead.

2. Safety — drain pending TRIM before tearing down the mount (ufsmount.h + ffs_alloc.c + ffs_vfsops.c): * add u_int um_trim_pending; to struct ufsmount; * atomic_add_int(&ump->um_trim_pending,1) when a TRIM bio is submitted, atomic_subtract_int(...) + wakeup() in ffs_blkfree_trim_task (also carries tp->i_ump so the task can find the counter); * in ffs_unmount, immediately before kfree(fs->fs_csp): while (ump->um_trim_pending) tsleep(&ump->um_trim_pending,0,"ufstrim",hz);

This turns the implicit "umount usually waits long enough" into a hard guarantee: kfree(fs/ump) cannot run until every deferred ffs_blkfree_trim_task has completed and decremented the counter.

Phase 8 validation (built + booted the fixed kernel)

• Baseline (unpatched #0): mount ufs+trim, write/unlink/umount → 0 FREEBLKS (TRIM dead), no panic.
• Full-fix kernel (kern.version 13:01:29, sha256 a0b2864db1c8836382acbf48ff4f1556ce4d3dd7cb67a675158263accbe7f746): mount ufs+trim, write/unlink/umount ×5 → 675 FREEBLKS flow (TRIM now operational), every umount returns rc=0, no panic / no kernel warning, deferred completions == FREEBLKS count (810 incl. timed run). Timed: unlink+unmount = 2932 ms (drain holds umount until the deferred tasks finish, then completes cleanly).

The fix therefore (a) makes async TRIM functional and (b) provably closes the latent UAF. recommended_fix: supersedes the finding's proposal (the finding proposed only the drain; the drain is insufficient on its own because without the mount-pointer fix TRIM stays dead, and the mount-pointer fix without the drain would expose the UAF — both must ship together).

6. PoC changes

• asyncd.c (+ Makefile): new — root-loaded KLD providing the slow async TRIM disk that QEMU hardware lacks; needed to exercise the TRIM bio path at all.
• trim_uaf.c, trim_race.c: syscall harnesses that mount ufs+trim directly (bypassing the userland da-only gate), create/delete files, and race umount.
• fix.diff: the validated two-part fix described above.

7. Honest impact / classification

• As filed (reachable UAF on current master): false positive. The path is dead code; the UAF cannot occur. Severity should be downgraded or the finding re-filed as "latent UAF + dead async-TRIM feature".
• Real bugs confirmed during verification: (1) ffs_blkfree MNT_TRIM gate uses the wrong mount pointer — FFS async TRIM is completely non-functional; (2) missing taskqueue_drain of swi TRIM tasks in ffs_unmount — a latent UAF that becomes live if/when (1) is fixed. Both are closed by fix.diff.
• No privilege boundary is crossed (the path is root-only on the default guest); no escalation chain applies.