DF-2792 — sys_ioprio_get(PRIO_PGRP) compares p_nice but assigns p_ionice

What

Copy-paste bug at sys/kern/kern_resource.c:365-369: the PRIO_PGRP scan of sys_ioprio_get() gates each member on p->p_nice (the CPU nice) but assigns p->p_ionice, while the PRIO_PROCESS (:340-352) and PRIO_USER (:399-413) paths compare p_ionice. The intended result is the maximum ionice of the group; the actual result is order-dependent garbage, and the call can even return ESRCH despite live members (when no member's nice exceeds the running high / the sentinel IOPRIO_MIN-2 = -1).

Build

cc -O2 -o ioprio_pgrp ioprio_pgrp.c

Run (unprivileged, deterministic, no race)

./ioprio_pgrp

Expected output

members ionice: parent=1 childA(pid A)=2 childB(pid B)=8
ioprio_get(PRIO_PGRP,  P)  = 2   (correct max = 8)
ioprio_get(PRIO_USER, uid) = 8
REPRODUCED: pgrp result 2 != expected max 8

Reproduced identically on the stock kernel (#0) and on the DF-2791-patched kernel (#1) — independent of that fix.

Fix

fix.diff — compare p->p_ionice instead of p->p_nice (one line). Authored post-verification; kernel rebuild for this one-liner was not performed (fix_status: not_testable).

DF-2792 VERDICT

Finding: sys_ioprio_get() PRIO_PGRP member scan uses the wrong field in its comparison (sys/kern/kern_resource.c:366-368).

Status: REPRODUCED (deterministic, unprivileged). Severity Low (correctness bug in a query API; no memory-safety impact).

Root cause

LIST_FOREACH(p, &pg->pg_members, p_pglist) {
        if (PRISON_CHECK(curtd->td_ucred, p->p_ucred) &&
            p->p_nice > high)          /* <-- should be p->p_ionice */
                high = p->p_ionice;
}

high is initialized to IOPRIO_MIN-2 (-1). p_nice is the CPU nice (-20..20, kern_resource.c donice :301-307); p_ionice the I/O nice (1..10, doionice :539-548). The USER-path callback and the PROCESS path both compare p_ionice; only the PGRP path compares p_nice, so members are admitted/skipped based on an unrelated field and the returned "max" is whatever the interleaving of nice vs running-high produces: order-dependent, wrong, or the sentinel (-1) → spurious ESRCH (:385-388) when every member's nice fails the comparison.

Run

Guest dfbsd 6.5-DEVELOPMENT X86_64_GENERIC #0, uid 1001. Parent+2 children in one pgrp; parent ionice 0 (clamped to 1), childA nice 5/ionice 2, childB nice 1/ionice 8:

ioprio_get(PRIO_PGRP, 965)  = 2   (correct max = 8)
ioprio_get(PRIO_USER, uid)  = 8      <- correct path proves the intent

Reproduced twice (run.log on stock kernel; run.2.log on the kernel patched for DF-2791 — unrelated file regions).

Impact ceiling

Wrong query result for an unprivileged, jail-aware (PRISON_CHECK intact) API: userland scheduling heuristics get a wrong I/O priority for a process group. No disclosure (values belong to visible processes only), no corruption, no privilege interaction. Low severity.

Fix validation

fix.diff (one-line: p->p_nice → p->p_ionice in the comparison). Not rebuilt into a kernel — deterministic userspace-visible behavior, one-line change, validated by inspection against the correct USER/PROCESS paths (fix_status: not_testable).