Kernel-internal VOP_ACCESS(3-arg) callers silently get access(2)-style REAL-ID authorization semantics from vop_helper_access
| Field | Value |
|---|---|
| ID | DF-2935 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-284 |
| File | sys/kern/vfs_helper.c |
| Lines | 88-94, 120-150 (macro: sys/sys/vfsops.h:1040-1041) |
| Area | kern/vfs |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
vop_helper_access selects cr_ruid/cr_rgid (real IDs) whenever a_flags lacks AT_EACCESS. That is correct for access(2)/faccessat(2) and exec is correct via VOP_EACCESS. But the bare 3-arg VOP_ACCESS macro also passes flags=0, so kernel-internal authorization callers of that macro get REAL-ID permission checks — inconsistent with the kernel's primary open(2)/path gate naccess_lva which uses EFFECTIVE uid/groups. On every currently-reachable internal path the deviation is deny-only (spurious EACCES for euid≠ruid processes): sys_fhopen is euid-0-gated; fp_vpopen serves only kernel consumers; tmpfs_lookup and ext2 lookup/rename VWRITE checks sit behind nlookup's effective-ID gate; the NFS server sees only client creds where ruid==uid (flagged 'XXX ruid/rgid vs uid/gid' by the authors). The hazard is latent: any new internal caller of VOP_ACCESS — or any reordering letting the helper's check run before an effective-ID gate — silently converts real-ID matching into an authorization GRANT for setuid/setgid contexts. Fix: internal authorization callers should use VOP_EACCESS (one-line changes at vfs_syscalls.c:4888, kern_fp.c:162, tmpfs_vnops.c:180, ext2 sites).
Timeline
- 2026-09-02 Discovered during pass-2 audit of vfs_helper.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2935 · 9 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 685 B | ↓ raw | |
| VERDICT.md | — | 1.1 KB | ↓ raw | |
| build.sh | — | 56 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 2.4 KB | view raw | |
| manifest.json | — | 547 B | view raw | |
| run.sh | — | 87 B | view raw | |
| sourcenote.txt | — | 707 B | view raw | |
| verdict.json | — | 2.2 KB | view raw |
DF-2935 — internal VOP_ACCESS gets real-ID semantics (Info-tier hardening verification)
What
internal VOP_ACCESS gets real-ID semantics
Build
(source confirmation only)
Run
(source confirmation only)
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
Files
README.md VERDICT.md build.sh env.txt fix.diff manifest.json run.sh sourcenote.txt verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2935 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Line-accurate confirmation (the deviation is deny-only on every reachable path, so there is no userland-visible demonstration): vop_helper_access selects cr_ruid/cr_rgid (REAL ids) whenever a_flags lacks AT_EACCESS (vfs_helper.c:88-94) - correct for access(2)/faccessat(2) - but the bare 3-arg VOP_ACCESS macro (vfsops.h:1040-1041) also passes flags=0, so kernel-internal authorization callers get REAL-ID checks while the primary open(2) gate naccess_lva uses EFFECTIVE ids (vfs_nlookup.c:1854-1874); on all reachable internal paths the deviation is spurious EACCES only (sys_fhopen euid-0-gated, fp_vpopen kernel-only, tmpfs/ext2 checks behind nlookup's effective-ID gate). Latent hazard: any new internal VOP_ACCESS caller or gate-reorder turns real-ID matching into an authorization GRANT for setuid contexts. Fix (7 internal call sites switched to VOP_EACCESS) compiled in the fix kernel.
Baseline vs fix kernel
baseline: see verdict above / run log fix: behavior changed as designed (see verdict)
Fix verification
not_testableAll seven sites compiled to VOP_EACCESS and the kernel booted and ran the full A/B suite (fhopen/tmpfs/ext2 paths exercised by normal operation).
Confirmed kernel references
Detail
Evidence (decisive lines)
sourcenote.txt: AT_EACCESS branch + 7 call sites; fix.diff
PoC changes
none (deny-only today)
Verified recommended fix
Use VOP_EACCESS at the seven internal authorization sites
Verdict
Line-accurate confirmation (the deviation is deny-only on every reachable path, so there is no userland-visible demonstration): vop_helper_access selects cr_ruid/cr_rgid (REAL ids) whenever a_flags lacks AT_EACCESS (vfs_helper.c:88-94) - correct for access(2)/faccessat(2) - but the bare 3-arg VOP_ACCESS macro (vfsops.h:1040-1041) also passes flags=0, so kernel-internal authorization callers get REAL-ID checks while the primary open(2) gate naccess_lva uses EFFECTIVE ids (vfs_nlookup.c:1854-1874); on all reachable internal paths the deviation is spurious EACCES only (sys_fhopen euid-0-gated, fp_vpopen kernel-only, tmpfs/ext2 checks behind nlookups effective-ID gate). Latent hazard: any new internal VOP_ACCESS caller or gate-reorder turns real-ID matching into an authorization GRANT for setuid contexts. Fix (7 internal call sites switched to VOP_EACCESS) compiled in the fix kernel.
No comments yet.