DF-5832 — NCF_WXOK "world r+x" cache flag resurrection race: directory search-permission revocation does not take effect

What

naccess() caches the fact that a directory is searchable by everyone in the namecache flag NCF_WXOK and uses it as a fast path that bypasses the VEXEC directory-search permission check entirely:

    sys/kern/vfs_nlookup.c:1616-1621
    if (error == 0 && nflagsp == NULL &&
        nflags == NLC_EXEC && (ncp->nc_flag & NCF_WXOK)) {
        if (nchislocked == 2)
            cache_unlock(nch);
        return 0;           /* traversal allowed, unchecked */
    }

The flag is (re)computed from a VOP_GETATTR_LITE snapshot and written while holding the ncp only shared:

    sys/kern/vfs_nlookup.c:1720-1723
    cflags = 0;
    if (lva.va_type == VDIR &&
        (lva.va_mode & S_WXOK_MASK) == S_WXOK_MASK) {
        cflags |= NCF_WXOK;
    }
    ...
    sys/kern/vfs_nlookup.c:1758-1762
    atomic_clear_short(&ncp->nc_flag, (... | NCF_WXOK | ...) & ~cflags);
    atomic_set_short(&ncp->nc_flag, cflags);

chmod(2) clears the cached flag with cache_inval_wxok():

    sys/kern/vfs_cache.c:2054-2070
    void
    cache_inval_wxok(struct vnode *vp)
    {
        spin_lock(&vp->v_spin);
        TAILQ_FOREACH(ncp, &vp->v_namecache, nc_vnode) {
            if (ncp->nc_flag & (NCF_WXOK | NCF_NOTX))
                atomic_clear_short(&ncp->nc_flag,
                           NCF_WXOK | NCF_NOTX);
        }
        spin_unlock(&vp->v_spin);
    }

called from setfmode() (sys/kern/vfs_syscalls.c:3422) right after VOP_SETATTR.

The clear and the set are not serialized against each other. cache_inval_wxok never takes the ncp lock; the setter holds it only shared. An naccess() that is in flight across the chmod transition — VOP_GETATTR_LITE executed before the mode change commits, atomic_set_short executed after cache_inval_wxok ran — writes NCF_WXOK back after the clear, from the stale pre-chmod attribute snapshot. Because the fast path at :1616-1621 returns immediately while NCF_WXOK is set and nothing else ever rechecks the mode while the flag stands, the resurrected grant persists indefinitely — until someone chmods the directory again.

Attack: while the administrator (or any owner) revokes search permission on a formerly world-r+x directory (e.g. chmod 0700 on a shared staging dir), an unprivileged attacker keeps modifying lookups racing through that directory (unlink("D/nonexistent") in a loop: NLC_DELETE makes naccess(D, NLC_EXEC, &dflags) take the full path, so every iteration performs GETATTR + flag-write on D — and a DELETE-on-nonexistent does not run any further full-path naccess on D afterwards, so a straddling worker's resurrection survives its own syscall). If any one lookup straddles the chmod, the attacker retains the ability to traverse/list the directory forever, reaching files inside it whose own modes permit access. Only the directory VEXEC check is bypassed (create/delete still require the real write permission), so the impact is unauthorized traversal/read access inside the restricted directory.

Files

• wxokrace.c — self-contained rig (root orchestrator, nobody workers and prober, pipe-burst barrier).
• run.sh — build + run: /tmp/wxokrace /var/tmp/wxok <rounds> <workers> <window_us>.
• run.log, run.2.log, run.3.log — race runs.
• fix.diff — verified fix.

Reproduce

In the guest as root:

sh /root/poc/DF-5832/run.sh

Expected (vulnerable kernel): within minutes the rig prints

WIN at round N: nobody stat(/var/tmp/wxok/probe) succeeds while dir mode is 0700
BYPASS DEMONSTRATED

i.e. an unprivileged stat() of a file inside a 0700 root:wheel directory succeeds — the chmod 0700 revocation was undone by the race and the stale NCF_WXOK grant is still being honored. Control (no race involved): chmod 0700 an idle formerly-0777 directory and the same stat returns EACCES (the flag is cleared and revalidated by the full path).

Fix

Serialize the clear with the update: cache_inval_wxok() must lock each ncp (exclusively) before clearing it, and setfmode() must call it without holding the vnode locked (the ncp exclusive lock order is ncp-first; taking it under a held vnode lock would deadlock against naccess()'s shared-ncp -> vget(shared-vp) sequence). See fix.diff.

DF-5832 VERDICT — NOT REPRODUCED on this guest (race-dependent); root cause code-proven

Bottom line

The race did not land within ~80,000 rounds across four rig designs on the 6-vCPU guest, so I am honestly classifying this as not_reproduced (impact as observed: none). The root cause, however, is structurally certain from the code and I recommend fixing it on the strength of the inspection proof — a permission-revocation mechanism that can silently fail to take effect is not something to leave in a kernel path every stat/open/exec traverses.

What is proven (by code + controls)

1. The fast path trusts the flag with no revalidation (vfs_nlookup.c:1616-1621): nflags == NLC_EXEC && nflagsp == NULL && (ncp->nc_flag & NCF_WXOK) → return 0 — the VEXEC directory-search check is skipped entirely.

2. The setter is unsynchronized with the clearer. The setter (naccess, vfs_nlookup.c:1720-1762) computes cflags from a lockless VOP_GETATTR_LITE snapshot and writes ncp->nc_flag while holding the ncp only shared (locked at :1630, held through the write to :1771). The clearer (cache_inval_wxok, vfs_cache.c:2054-2070, called from setfmode, vfs_syscalls.c:3422, immediately after VOP_SETATTR) takes no ncp lock at all — only vp->v_spin. There is therefore no ordering between a concurrent clear and set: clear → stale-set is an allowed interleaving, and the stale set wins because nothing rechecks the mode while the flag stands.

3. The observable halves of the flag lifecycle work (controls, see README): an unprivileged stat of a file inside a 0700 root:wheel formerly-0777 directory correctly returns EACCES after a quiet chmod, and succeeds while the directory is 0777.

4. Why the straddle is hard to hit. For the resurrection the setter must be stalled (interrupt/preemption) inside its ~150ns GETATTR → atomic_set span for longer than the chmod's mode-commit → cache_inval_wxok gap (~0.3–2 µs), with the mode commit landing inside that span. My rigs produced straddle candidates (burst-timed one-shot workers with the commit timed into the in-flight window) and amplified in-span preemption (cross-CPU IPI storm via mmap/munmap churn + ping flood), but the joint probability evidently remained below what ~80k rounds sampled on a virtualized guest.

Rig summary (what was tried)

Worker op: unlink("D/nope") (nonexistent) — a modifying lookup (NLC_DELETE ⇒ naccess(D, NLC_EXEC, &dflags) full path ⇒ GETATTR + flag write), and DELETE-on-nonexistent skips the parent-write recursion (vfs_nlookup.c:1571-1575 requires nc_vp != NULL for NLC_DELETE), so a straddling worker's write is the last one in its own syscall. Probe: stat("D/probe") as nobody — succeeds only via the resurrected flag (shortcut), EACCES otherwise.

Impact if manifested (theoretical, per the root cause)

Directory search-permission revocation does not take effect: an unprivileged user retains traversal/list access to a directory after chmod 0700, indefinitely (until the next chmod of that directory), reaching files inside it whose own modes permit access. Only the directory VEXEC check is bypassed (create/delete still check the real directory write permission).

Fix (proposed; not build-validated since the race did not reproduce)

fix.diff: serialize the clear with the setter — cache_inval_wxok() locks each ncp exclusively before clearing (restart-safe scan holding only an ncp reference across the lock), and setfmode() drops the vnode lock (keeping a reference) before calling it, because taking the ncp exclusive lock under a held vnode lock would invert the ncp-first lock order against naccess()'s shared-ncp → vget(shared-vp) sequence. With this ordering, any setter whose GETATTR predates the mode change has its write ordered before the clear (it holds the ncp shared across GETATTR→atomic_set), so the clear is always the last write.

Kernel references

• sys/kern/vfs_nlookup.c:1616-1621 — fast path trusts NCF_WXOK unchecked
• sys/kern/vfs_nlookup.c:1720-1723 — NCF_WXOK computed from GETATTR_LITE snapshot
• sys/kern/vfs_nlookup.c:1758-1762 — flag write under shared ncp lock
• sys/kern/vfs_nlookup.c:1630-1658 — shared lock spans GETATTR→write
• sys/kern/vfs_cache.c:2054-2070 — cache_inval_wxok takes no ncp lock
• sys/kern/vfs_syscalls.c:3411-3424 — setfmode: SETATTR then inval
• sys/vfs/tmpfs/tmpfs_vnops.c:404-431 — lockless GETATTR_LITE (tmpfs)
• sys/vfs/hammer2/hammer2_vnops.c:370-424 — seqlocked GETATTR_LITE (hammer2)

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.