A race condition that requires root to set up and, when won, gives the winner root-equivalent capability is not an elevation of privilege. It is a tautology dressed as a vulnerability. This post is about finding a genuine pattern in the XNU kernel's exec path, understanding exactly why it doesn't matter, and coming to terms with the fact that Apple's closure was not only correct but was the only reasonable outcome.

Situation

In 1994, in my first weeks at University College Scarborough, I found a SUID binary on the university's Unix systems. I knew what SUID meant — the Set User ID bit causes an executable to run with the permissions of its owner rather than the caller — but I had not previously thought hard about what it implied for the operating system's trust model. If the kernel is going to honour those bits, it has to be right about what it is executing and who set the bits. That realisation — that the kernel's exec path is a site of significant trust — took root then and has informed a lot of my subsequent work.

Thirty years later, reading through bsd/kern/kern_exec.c in the XNU source, I noticed something that brought that 1994 moment back.

Investigation

XNU's exec_activate_image() is the function responsible for loading and activating an executable image during an execve(2) call. Early in its execution, it fetches the vnode attributes for the target file — including the SUID and SGID permission bits — and caches them in a structure called ip_origvattr. These cached attributes are later consulted when the kernel decides whether to honour the SUID bit and elevate the effective UID of the new process.

The pattern is real. The stale-vattr window exists. TOCTOU vulnerabilities in exec paths have a genuine history — they are a well-understood class of kernel bug, and instances of them in other operating systems have led to exploitable local privilege escalation. The instinct to look here was not unreasonable.

Finding

Apple's response was precise: "Root prerequisite exceeds exploit; no security boundary crossed."

To exploit the race, an attacker needs to arrange an atomic file swap between the attribute fetch and the exec. On macOS, the mechanisms available for doing this — bind mounts, union mounts, or crafted volume structures — require root to set up. There is no unprivileged path to the necessary mount manipulation on a production macOS system. If you can set up the race, you already have root. If you already have root, winning the race gives you nothing you do not already have.

Implication

The stale ip_origvattr pattern is architecturally interesting as a code-quality observation. In a future system where root's privileges are more tightly partitioned — where specific capabilities are separated from general root access — the same race window could become significant. On macOS as it stands today, it does not cross a security boundary.

There is also a broader point about how to evaluate TOCTOU findings before submission. A race condition in a privileged path is not automatically a privilege escalation. The question is always: what does an attacker need to enter the race, and what do they gain if they win? If the entry cost equals or exceeds the prize, the finding is closed before it begins. I did not work through that arithmetic carefully enough before submitting.

In my view, Apple's threshold for closing this was entirely reasonable. The research community has long understood that root-prerequisite bugs do not generally constitute actionable security findings on consumer operating systems, and macOS is no exception. Acknowledging this honestly is more useful than arguing at the margins.

Proof of concept

#!/bin/bash
# SUID TOCTOU concept demonstration
# REQUIRES ROOT to set up the mount manipulation
# This script demonstrates why Apple closed the report:
# root is a prerequisite, and the exploit gains nothing
# that root does not already provide.
# Own hardware only. All testing on SRDP device.

if [ "$(id -u)" != "0" ]; then
    echo "This PoC requires root to set up the mount manipulation."
    echo ""
    echo "If you already have root, this race gives you nothing."
    echo "That is precisely why Apple closed the report:"
    echo "  'Root prerequisite exceeds exploit; no security boundary crossed.'"
    echo ""
    echo "Entry cost = prize. Finding closed."
    exit 1
fi

# Concept:
# 1. Create a non-SUID binary at path A.
# 2. Create a SUID binary at path B.
# 3. Use a root-controlled bind mount to swap A -> B atomically.
# 4. Time the swap to occur after exec_activate_image() caches ip_origvattr
#    (reads A's non-SUID attributes) but before image activation.
# 5. Kernel activates B (SUID) while ip_origvattr reflects A (non-SUID).
#    OR: kernel activates A (non-SUID) while ip_origvattr reflects B (SUID).
#
# Source reference: bsd/kern/kern_exec.c
# ip_origvattr is populated at exec_activate_image() entry.
# It is not re-validated before image activation.
# The race window is narrow (microseconds) and requires root to exploit.
#
# Security boundary analysis:
#   Entry cost:  root (required for mount manipulation)
#   Prize:       root-equivalent (SUID execution or SUID suppression)
#   Delta:       zero — no boundary crossed
#   Conclusion:  not an actionable vulnerability

echo "Root prerequisite confirmed."
echo "The ip_origvattr stale-vattr pattern is a code-quality observation."
echo "It is not an exploitable vulnerability on current macOS."
echo ""
echo "csrutil status:"
csrutil status

Disclosure note

Final thought

In 1994 I learned that SUID bits have to be set by something the kernel trusts. That trust runs all the way down to the exec path, to the vnode attributes, to the decision the kernel makes about who is allowed to set those bits. The interesting question is always: what does it cost to interfere with that chain? In this case, it costs root. And root, as Apple correctly observed, is already the answer.

Are you there?