sys_setgroups publishes the COW credential before mutating it: mid-copyin window exposes mixed old/new group sets to other threads, and a failing copyin leaves the credential partially mutated despite the error return

Summary

sys_setgroups calls cratom_proc(p) at :682, which installs the new credential as p_ucred BEFORE the group vector is filled in. The copyin at :692 can take a user fault and block; during that window any other thread entering the kernel caches the published-but-mid-mutation cred as td_ucred and executes group checks against cr_groups holding a mix of old and new gids while cr_ngroups still holds the old count. Additionally, when copyin faults partway, the syscall returns the error but the published credential keeps the partially overwritten cr_groups — POSIX expects no change on failure. All accesses stay in-bounds (not a memory-safety bug): impact is a transient self-race on group-membership checks and a state change despite an error return. Unprivileged callers cannot reach the code (SYSCAP gate).

Recommended fix

Copy the group vector into a stack temp before publishing, then atomically install it into the cred under p_token (full-atomicity alternative: build a complete new cred and publish with a single p_ucred store, as FreeBSD does).

Timeline

• 2026-08-30 Discovered during pass-2 audit of kern_prot.c (GLM 5.3).