Summary: procps-ng, procps is vulnerable to a process hiding through race condition. 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. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.
Please note that GLSA 201805-14 gives the incorrect impression that following the steps in this GLSA will result in CVE-2018-1121 being addressed, when it hasn't been yet.
(In reply to Daniel Robbins from comment #1) > Please note that GLSA 201805-14 gives the incorrect impression that > following the steps in this GLSA will result in CVE-2018-1121 being > addressed, when it hasn't > been yet. Fixed in GLSA 201805-14.
RedHat seems to believe this is invalid, "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." Any objection to us marking invalid as well?