shmfork() bcopy's transient shmmap_s reservation state: fork landing in shmat's blocked window permanently burns a SHMSEG slot in the child (and gives it an un-accounted, un-shmdt-able mapping)

Summary

sys_shmat marks a shmmap_s slot reserved=1 for the duration of its blocking vm_map_find window; shmfork bcopy's the ENTIRE array including that transient state. The child's copy of reserved=1/shmid=−1 can never be cleared (only the parent's in-flight shmat clears its own array), permanently shrinking the child's usable shmseg slots by one per hit; if the fork lands after vm_map_find inserted the entry, the child's copied vm_map holds the mapping while its vm_shm entry stays shmid=−1 — shmdt/exit skip it (refcounting still balances via the map teardown, so a leak, not corruption). Unpriv fork-vs-shmat racing; per-process slot exhaustion + loss of SysV accounting. Fix: un-reserve inherited slots when copying in shmfork.

Timeline

• 2026-09-02 Discovered during pass-2 audit of sysv_shm.c (GLM 5.3).