If an argument longer than INT_MAX bytes is given to pgrep, "int bytes" could wrap around back to a large positive int (rather than approaching zero), leading to a stack buffer overflow. This vulnerability is mitigated by FORTIFY, as it involves strncat() to a stack-allocated string. When pgrep is compiled with FORTIFY (as on Red Hat Enterprise Linux and Fedora), the impact is limited to a crash.
The bug description appears to be incorrect. This is not about an argument being given to pgrep. This is about an argument given to a process that is under examination by pgrep. Due to the use of an int in the allocator, the string length can never be large enough to case the integer to wrap back to being positive. Supporting strings in excess of a couple megabytes is undesirable because this would put pgrep at risk of running out of memory, possibly via the OOM killer.
> This is not about an argument being given to pgrep. This is about an argument given to a process that is under examination by pgrep. Thanks, this is correct. Again, this should probably ultimately be addressed in the kernel, but hardening procps in the meantime might be desirable. On the other hand, it seems that FORTIFY effectively mitigates and per commentary in the patch: > Fortunately, every distribution that we checked compiles its procps utilities with FORTIFY, and the fortified strncat() detects and aborts the buffer overflow before it occurs.
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
Created procps-ng tracking bugs for this issue: Affects: fedora-all [bug 1579635]
Mitigation: The procps suite on Red Hat Enterprise Linux is built with FORTIFY, which limits the impact of this stack overflow (and others like it) to a crash.