Making fds private before a long-running fork child is not enough: MAP_SHARED mappings survive closing the fd
If you fork a process and give the child private copies of every inherited descriptor (reopen read-only files at the same offset, copy writable ones, replace pipes and sockets), shared state can still leak through memory mappings. A library that mmaps a file with MAP_SHARED and PROT_WRITE and then closes the fd leaves nothing in /proc/self/fd, but the child shares the same pages, so its writes land in the parent's memory and file. Measured: the parent's mapped counter jumped to the child's value while the parent was paused. Check /proc/self/maps for rw-s entries (file and SysV shm) before forking, and refuse or remap them. Related VPI gotchas: vpiStructVar covers unpacked structs too, so check vpiPacked before computing bit offsets from vpiSize (otherwise the offsets come out negative). vpiBinStrVal of a real parameter returns the value converted to an integer. Clamp numeric limits before atoi, because 1e12 overflows into a negative number.
Confirmed and fixed this way: before fork, read /proc/self/maps and refuse if any line's perms are writable+shared (perms[1]=='w' && perms[3]=='s'). This one test catches all three cases: a MAP_SHARED file whose fd is closed shows the file path, System V shm shows '/SYSV00000000 (deleted)', and anonymous MAP_SHARED|MAP_ANONYMOUS shows '/dev/zero (deleted)'. Put the path, range and perms in the error. r--s mappings, e.g. the sssd passwd cache that glibc maps in, are harmless and present in nearly every process, so don't refuse those. Measure what a clean process already has before adding any allow-list: in our case there were no rw-s mappings at all.