# DF-3259 VERDICT — /proc/pid/rlimit missing per-op authorization

## Status: REPRODUCED (authorization bypass / cross-uid info disclosure), Low severity

## Root cause

`sys/vfs/procfs/procfs_rlimit.c:55-110` — `procfs_dorlimit()` contains no
credential check of any kind. The only filter is lookup-time process
visibility: `sys/vfs/procfs/procfs_vnops.c:809-811,833` hide other-uid pid
directories only when `security.ps_showallprocs == 0`; guest default is
`security.ps_showallprocs: 1` (verified). Every comparable procfs op re-checks
`CHECKIO(curp, p) || p_trespass(curp->p_ucred, p->p_ucred)` per operation
(procfs_regs.c:60, procfs_fpregs.c:59, procfs_dbregs.c:62,
procfs_mem.c:189, procfs_ctl.c:126); rlimit is the outlier. This is the
DF-3224 per-op lesson applied in reverse: the gate is not merely open-time —
it is absent entirely.

## Observation

uid=1001 (maxx) opened and read `/proc/1/rlimit` (init, uid 0): 209 bytes,
full soft/hard limit table of the root process (run.log, run.2.log —
reproduced twice, stable). Discloses limit-based fingerprinting of security
daemons (e.g. memlock/nofile of privilege-separated services).

## Impact ceiling

Low: numeric configuration disclosure of arbitrary local processes. No
memory-safety impact; no privilege escalation. (Linux gates the same file
behind PTRACE_MODE_READ; the info is considered worth gating there.)

## Fix validation

Not kernel-rebuilt for this finding (Low severity, authorization gate only —
the orchestrator's Phase V budget went to the DB-3258 fix build). `fix.diff`
adds the exact sibling gate at procfs_rlimit.c:63; pattern is used verbatim
at five neighboring call sites. fix_status: not_testable (no rebuild), with
the diff provided for the upstream PR.

## Secondary result (DF-0935 boundary, empirical)

The same PoC maximizes all 12 rlimits to the highest values an
unprivileged process can reach (hard-limit lowering to
9223372036854775806 is unprivileged — kern_plimit.c:294-303 — and the
kernel then clamps data/stack/nofile/nproc/posixlocks to
maxdsiz=34359738368, maxssiz=536870912, maxfilesperproc=32528,
maxprocperuid=2033, maxposixlocksperuid=32528 — kern_plimit.c:316-379).
Resulting formatter output: **431 bytes** (predicted == actual), under
psbuf[512] by 81 bytes. DF-0935 (unfixed in tree) therefore remains
unreachable with default caps — confirming pass-1; overflow requires
relaxing maxdsiz/maxssiz-type loader tunables (root), after which the
reader must merely read a suitably-limited root process's rlimit.

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