An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration.
Statement: The /proc filesystem is not a reliable mechanism to account for processes running on a system, as it is unable to offer snapshot semantics. Short-lived processes have always been able to escape detection by tools that monitor /proc. This CVE simply identifies a reliable way to do so using inotify. Process accounting for security purposes, or with a requirement to record very short-running processes and those attempting to evade detection, should be performed with more robust methods such as auditd(8) (the Linux Audit Daemon) or systemtap.
Acknowledgments: Name: Qualys Research Labs
Public via: http://seclists.org/oss-sec/2018/q2/122
External References: https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt
AFAIK, this CVE had too low severity and significant drawback to user/developer experience (see comments above). Procps provides a set of diagnostic tools that only transform procfs data to a readable form, most of them a oneshot application. Not even the upstream reflected this issue in the patches of the Qualys reports. The gain/loss ratio was not satisfactory. My POV only.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days