kern/58822: close-on-exec is broken for dup3 and opening cloning devices

[campbell+netbsd%mumble.net@localhost]

>Number:         58822
>Category:       kern
>Synopsis:       close-on-exec is broken for dup3 and opening cloning devices
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 10 14:20:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetBSD O'Cloexecution
>Environment:
>Description:
Various paths processing *_CLOEXEC flags fail to correctly set up the full close-on-exec state for the file descriptors in question, so they are not, in the end, actually closed on exec.

In particular, each struct fdfile object, representing a process's reference to a file, has a bit ff_exclose which determines whether exec should close it.  But the process's struct filedesc object, representing a table of file descriptors, also has a bit fd_exclose summarizing whether _any_ of its struct fdfiles has ever had ff_exclose set.  If fd_exclose isn't set, exec doesn't bother to examine any individual struct fdfiles to check for ff_exclose and close them.

The subroutine fd_set_exclose() sets ff_exclose for the individual file reference, and sets fd_exclose if close-on-exec is being enabled.

However, several paths -- in fd_dup, fd_dup2, and fd_clone -- only set ff_exclose and failed to set fd_exclose or call fd_set_exclose(), so the summary was not updated, and if no other file descriptors were created with close-on-exec using another path, they are not actually closed on exec.
>How-To-Repeat:
1. open a file descriptor with fcntl(F_DUPFD_CLOEXEC), dup3(O_CLOEXEC), or open("/dev/drvctl") or some other cloning device readable by userland
2. exec a program that tries to use that file descriptor
3. ???
4. profit
>Fix:
https://mail-index.netbsd.org/source-changes/2024/11/10/msg154309.html

needs automatic test and pullup-9, pullup-10