DF-3182 — tmpfs usermount memory cap is attacker-declared: size_max is never clamped to pages_limit

What

tmpfs_mount computes a system cap pages_limit = vm_swap_max + vmstats.v_page_count / 2 (sys/vfs/tmpfs/tmpfs_vfsops.c:157) but then applies it only to the default (size_max == 0) case, halved. For any explicit size_max the mount takes the attacker's value verbatim — the OFF_TO_IDX(size_max) > pages_limit branch is deliberately unclamped (comment at :164-169: fstab boot-order concerns), up to OFF_TO_IDX(INT64_MAX) = 2^51 pages:

    } else if (OFF_TO_IDX(size_max) > pages_limit) {
        /* do not force pages = pages_limit ... */
        pages = OFF_TO_IDX(size_max);      /* no clamp! */
    } else {
        pages = OFF_TO_IDX(size_max);      /* identical branch */
    }

There is no distinction between root mounts (where the fstab rationale may apply) and non-root usermounts: with vfs.usermount=1, any user mounting a tmpfs on a directory they own sets tm_pages_max (and the derived tm_nodes_max) arbitrarily (sys/kern/vfs_syscalls.c:151-155 — SYSCAP_NOMOUNT_TMPFS under __SYSCAP_NOROOTTEST, default creds are unrestricted). The ENOSPC machinery in tmpfs_reg_resize (tmpfs_subr.c:1007-1011) then compares against the attacker's number and never fires — the only backstop is real machine-wide memory exhaustion.

Reproduce (observed on the guest, unprivileged user maxx, vfs.usermount=1)

# ./umount_demo /home/maxx/dfm1
mounter uid=1001 euid=1001, spoofing ta_root_uid/gid=0, ta_size_max=1TiB
statfs: f_blocks=268435456 (x PAGE_SIZE = 1099511627776 bytes = 1024 GiB), ...

The designed cap on this guest (4 GB RAM, 4 GB swap) would be (1048576 + 520k)/2 ≈ 784k pages ≈ 3 GiB; the user-mounted tmpfs reports 268,435,456 pages (1 TiB), i.e. 341x past the intended bound. Writing past 3 GiB into such a mount succeeds (no ENOSPC) until the machine exhausts memory — unprivileged whole-system DoS (swap thrash/OOM), by design of the missing clamp.

Fix

For non-root mounters (cred->cr_uid != 0), clamp: if (pages > pages_limit) pages = pages_limit; (the boot-order rationale in the comment concerns root fstab mounts only). Optionally also enforce a global sum across user-mounted tmpfses.

DF-3182 verdict — REPRODUCED (mount-side limit derivation accepts attacker-declared size for usermounts)

Guest: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (INVARIANTS), 4.25 GB RAM, 4 GB swap, vfs.usermount=1 (set as root for the demo; it is the documented precondition for unprivileged mounts — default is 0).

As unprivileged user maxx (uid 1001), mounting a tmpfs on a self-owned directory with ta_size_max = 1 TiB:

statfs: f_blocks=268435456 (x PAGE_SIZE = 1099511627776 bytes = 1024 GiB)

The kernel-derived system cap for this machine would be pages_limit = vm_swap_max + v_page_count/2 = 1,568,895 pages, halved for defaults = 784,447 pages (~3 GiB). The user's mount stores tm_pages_max = 268,435,456 pages — 341x the intended bound — because tmpfs_vfsops.c:163-173 assigns pages = OFF_TO_IDX(size_max) in BOTH the over-limit and normal branches (the comment admits the clamp was dropped for boot-time fstab ordering; usermounts were not considered).

Consequence: the ENOSPC guard in tmpfs_reg_resize (tmpfs_subr.c:1007-1011) compares against the attacker's number and cannot fire; filling such a mount degrades only at whole-machine memory exhaustion (swap thrash/OOM) — an unprivileged system-wide DoS under vfs.usermount=1. The actual OOM wedge was not executed on the single-tenant guest to keep it usable for the other verifications; the bypass itself (f_blocks + successful writes into the mount beyond any kernel-derived cap) is captured in run.log.

Note: even without this bug, per-mount caps are per-mount (a user could stack several clamped mounts); the bug reduces the cost to one syscall and one mount and removes the kernel's own notion of a bound entirely. Rated Low-to-Medium accordingly (conditional on vfs.usermount=1).

Status: reproduced / impact=dos (limit bypass demonstrated; OOM consequence immediate) / confidence certain for the derivation, likely for the machine-wide impact.

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.)