DF-3183 — non-root tmpfs mounts take attacker-supplied root uid/gid (mode is sanitized, ownership is not) → statfs f_owner forgery + unmount-permission confusion

What

tmpfs_mount (sys/vfs/tmpfs/tmpfs_vfsops.c:142-155) copies ta_root_uid / ta_root_gid from the (fully user-controlled) struct tmpfs_mount_info and only sanitizes root_mode for non-root mounters:

    root_uid = args.ta_root_uid;        /* :142 — NOT sanitized below */
    root_gid = args.ta_root_gid;        /* :143 */
    root_mode = args.ta_root_mode;
    ...
    if (cred->cr_uid != 0) {
        root_mode = VREAD;          /* only mode is forced */
        ...
    }

Consequences for a vfs.usermount=1 unprivileged mount: * the tmpfs root directory is owned by any chosen uid/gid (e.g. 0); * tmpfs_statfs overwrites f_owner with tm_root->tn_uid (tmpfs_vfsops.c:494), and sys_unmount authorizes unmount by mp->mnt_stat.f_owner == cred->cr_uid || priv (sys/kern/vfs_syscalls.c:670) — so the forged uid can unmount the attacker's mount, and the real mounter is locked out.

Observed (guest, user maxx uid 1001, vfs.usermount=1)

mounter uid=1001 euid=1001, spoofing ta_root_uid/gid=0, ta_size_max=1TiB
statfs: f_blocks=268435456 ..., f_owner=0 (mounter is 1001)
root dir owner: uid=0 gid=0 mode=40600
unmount by mounter: FAILED (Operation not permitted) — f_owner forged to 0

Control run without the spoof unmounts fine (unmount by mounter: OK).

Fix

For non-root mounters force root_uid = cred->cr_uid; root_gid = cred->cr_gid; alongside the existing root_mode override, and stop overwriting f_owner in tmpfs_statfs (leave the mounter's uid recorded by the VFS layer).

DF-3183 verdict — REPRODUCED (non-root tmpfs mount forges root-dir uid/gid and statfs f_owner; unmount-permission confusion)

Guest: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (INVARIANTS), vfs.usermount=1, unprivileged user maxx (uid 1001).

Observed (run.log):

mounter uid=1001 euid=1001, spoofing ta_root_uid/gid=0, ta_size_max=1TiB statfs: f_blocks=268435456 ..., f_owner=0 (mounter is 1001) root dir owner: uid=0 gid=0 mode=40600 unmount by mounter: FAILED (Operation not permitted) — f_owner forged to 0

Control (no spoof): f_owner=1001, root dir uid=1001, unmount OK.

Source: tmpfs_mount copies args.ta_root_uid/ta_root_gid verbatim (tmpfs_vfsops.c:142-144) and sanitizes only root_mode for non-root (:151-155). tmpfs_statfs then publishes tm_root->tn_uid as f_owner (:494), and sys_unmount authorizes by mp->mnt_stat.f_owner == cred->cr_uid || priv (kern/vfs_syscalls.c:670). Net effects: 1. forged f_owner → the named uid can unmount the attacker's mount (or mount -u update check at vfs_syscalls.c:263), while the real mounter is locked out (demonstrated: EPERM self-lockout); 2. the root directory of a user-mounted tmpfs reports arbitrary ownership (uid=0 gid=0 demonstrated) — auditing/ownership confusion (files created within still belong to the creating users).

Impact ceiling is modest (no direct privilege gain — permission checks on the spoofed-owned directory do not help the non-owner mounter; mode is forced to 0600). Filed Low: ownership/f_owner forgery on a usermountable filesystem plus unmount authorization confusion.

Status: reproduced / impact=none (privilege-relevant confusion only) / confidence certain.

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)