DF-0621 — rip6_output priv check uses cr_uid==0 instead of capsicum

Bug

rip6_output (sys/netinet6/raw_ip6.c:297-299) computes the privileged flag for per-send cmsg (IPV6_NEXTHOP, IPV6_HOPOPTS, IPV6_DSTOPTS, IPV6_RTHDR, ...) using a weak credential test:

priv = 0;
if (so->so_cred->cr_uid == 0)
    priv = 1;

This priv flows to ip6_setpktoptions (raw_ip6.c:302) → ip6_setpktoption (sys/netinet6/ip6_output.c:2555) where it gates restricted IPv6 options (e.g. line 2712 if (!priv) return (EPERM) for IPV6_NEXTHOP; line 2763 for IPV6_HOPOPTS).

The sticky-option path (setsockopt via ip6_ctloutput) correctly uses the proper capsicum check at sys/netinet6/ip6_output.c:1156-1158:

privileged = (td == NULL ||
              caps_priv_check_td(td, SYSCAP_RESTRICTEDROOT)) ?
             0 : 1;

The inconsistency: rip6_output should use the same capsicum check but instead tests only cr_uid == 0.

Direction of the inconsistency (important)

This is NOT an "unpriv user gains privilege" bug. The check grants priv=1 only when cr_uid == 0 (root). It does NOT grant privilege to non-root users. The inconsistency is:

• A process with cr_uid == 0 but with the SYSCAP_RESTRICTEDROOT capability revoked (capsicum-sandboxed root) would still get priv=1 via rip6_output (the cmsg path), even though the setsockopt path would correctly deny it.

This is a defense-in-depth / hardening gap, not a privilege escalation. The bypass is of capability-based restrictions on an already-root credential.

Reachability on this guest

rip6_output is the pru_send for SOCK_RAW IPv6 sockets. Opening one requires SYSCAP_NONET_RAW (raw_ip6.c:530: caps_priv_check(..., SYSCAP_NONET_RAW | __SYSCAP_NULLCRED)). On this guest an unprivileged user (uid=1001) gets EPERM:

$ ./check
[*] DF-0621 reachability check
[*] trying to open AF_INET6 SOCK_RAW as uid=1001
[+] socket(AF_INET6, SOCK_RAW) FAILED: Operation not permitted (errno=1)
[+] expected: SYSCAP_NONET_RAW required (rip6_attach raw_ip6.c:530)
[+] => unprivileged user CANNOT reach rip6_output
[+] => DF-0621 is a root-only hardening gap, not unpriv->root

So: - An unprivileged user cannot reach rip6_output at all. - The only credential that experiences the wrong check is a capsicum-restricted root, which is a defense-in-depth scenario.

Fix

Use caps_priv_check_td(curthread, SYSCAP_RESTRICTEDROOT) to match the setsockopt path. See fix.diff.

DF-0621 — Verdict: NOT REPRODUCED (hardening inconsistency only)

Verdict

NOT REPRODUCED as an unprivileged escalation. The code-path inconsistency is real (confirmed by source trace) but the "privilege bypass" is in the wrong direction for unpriv users: it can only fail to deny a capsicum-restricted root credential. An unprivileged user (cr_uid != 0) gets priv=0 either way, and cannot even reach rip6_output because rip6_attach (raw_ip6.c:530) requires SYSCAP_NONET_RAW.

This is correctly classified as a Medium hardening / correctness finding, not a Critical/High escalation.

Source trace

• sys/netinet6/raw_ip6.c:297-299 — the weak check: c priv = 0; if (so->so_cred->cr_uid == 0) priv = 1;
• sys/netinet6/raw_ip6.c:302-304 — priv flows to ip6_setpktoptions(control, &opt, ..., priv).
• sys/netinet6/ip6_output.c:2555 — ip6_setpktoption takes priv parameter.
• sys/netinet6/ip6_output.c:2712 — if (!priv) return (EPERM); for IPV6_NEXTHOP.
• sys/netinet6/ip6_output.c:2763 — if (!priv) return (EPERM); for IPV6_HOPOPTS.
• sys/netinet6/ip6_output.c:1156-1158 — the correct check used by the setsockopt (sticky-option) path: c privileged = (td == NULL || caps_priv_check_td(td, SYSCAP_RESTRICTEDROOT)) ? 0 : 1;
• sys/netinet6/ip6_output.c:1871 — ip6_pcbopts (IPV6_PKTOPTIONS) hardcodes priv = 0 — a separate (also-incorrect-but-the-other-way) inconsistency noted by the reviewer.

Reachability test

• sys/netinet6/raw_ip6.c:530 — caps_priv_check(ai->p_ucred, SYSCAP_NONET_RAW | __SYSCAP_NULLCRED) gates raw IPv6 socket creation.
• Empirically on this guest: socket(AF_INET6, SOCK_RAW, IPPROTO_RAW) as uid=1001 → EPERM.
• Therefore an unprivileged user cannot reach rip6_output at all.

Impact ceiling

• No unpriv escalation demonstrable.
• Hardening gap: a capsicum-sandboxed root process (one that has had SYSCAP_RESTRICTEDROOT revoked but still has SYSCAP_NONET_RAW) could set IPV6_NEXTHOP via per-send cmsg even though the system policy intended to deny it. This is a real but narrow defense-in-depth concern.
• Realistic deployments rarely combine cr_uid==0 with capsicum restriction of SYSCAP_RESTRICTEDROOT, so practical impact is low.

Fix validation

The fix is one line: replace the weak cr_uid == 0 check with the proper caps_priv_check_td(curthread, SYSCAP_RESTRICTEDROOT). Validated by: 1. Source trace shows the fix is correct. 2. fix.diff applies cleanly with patch -p1 --dry-run against sys/netinet6/raw_ip6.c.

A kernel build/boot test is not strictly required for a hardening-only finding with no reproduced behavior to compare against, but the change is a 3-line surgical replacement that matches the existing pattern at ip6_output.c:1156.

Kernel references

• sys/netinet6/raw_ip6.c:297-299 — weak cr_uid check (BUG)
• sys/netinet6/raw_ip6.c:302-304 — priv flows to ip6_setpktoptions
• sys/netinet6/raw_ip6.c:530 — SYSCAP_NONET_RAW gate on raw IPv6 socket
• sys/netinet6/ip6_output.c:1156-1158 — correct capsicum check (setsockopt path)
• sys/netinet6/ip6_output.c:2555 — ip6_setpktoption priv parameter
• sys/netinet6/ip6_output.c:2712 — IPV6_NEXTHOP EPERM gate
• sys/netinet6/ip6_output.c:2763 — IPV6_HOPOPTS EPERM gate
• sys/netinet6/ip6_output.c:1871 — ip6_pcbopts hardcodes priv=0 (related inconsistency)