A small waitid() change [LWN.net]

System-call fuzzing work recently turned up an interesting problem on many Linux systems: depending on which init system is used, a process can create permanent zombie children by cloning a thread, calling ptrace() on it, then exiting. If the init system is not waiting for exiting processes in the right way, that particular thread will go unnoticed and unreaped; unlike other zombies, it will not roam the system searching for a cerebral-matter snack, but it will sit there forever using memory, which is bad enough.

This is, technically, not a kernel bug: a call to waitid() (which is what most init implementations evidently use) is not supposed to wait for children in the absence of the __WALL flag. But it is a denial-of-service vector, changing every init implementation is impractical, and, besides, the waitid() system call, unlike wait4(), does not even accept the __WALL flag. So Oleg Nesterov decided that this problem should be fixed in the kernel, even if the bug could be said to be elsewhere.

So, as of 4.7, a call to waitid() will wait for child processes running under ptrace(). It will also accept the __WALL flag, but that flag will not actually be necessary to prevent this particular zombie invasion. As Oleg noted in the patch changelog, this is an ABI change: "__WCLONE and __WALL no longer have any meaning for debugger. And I can only hope that this won't break something, but at least strace/gdb won't suffer." The change seems unlikely to cause problems further afield, but one never knows; if problems are found during the 4.7 development cycle, this change may have to come back out.