A bug reporter [1] that claims he has, or can produce, a code execution exploit against grep < 2.11. I've verified that our grep 2.10 package segfaults on the amd64 platform with the simple reproducer: $ perl -e 'print "x"x(2**31)' | grep x > /dev/null Segmentation fault (core dumped) This specific problem was patched [2] with the following checkin: http://git.savannah.gnu.org/cgit/grep.git/commit/?id=cbbc1a45b9f843c811905c97c90a5d31f8e6c189 This checkin adds this text to the NEWS file: + grep no longer dumps core on lines whose lengths do not fit in 'int'. + (e.g., lines longer than 2 GiB on a typical 64-bit host). + Instead, grep either works as expected, or reports an error. + An error can occur if not enough main memory is available, or if the + GNU C library's regular expression functions cannot handle such long lines. + [bug present since "the beginning"] Please assign a CVE number for this problem. Several other checkins around the 2.11 timeframe also look like they may be security-relevant: PCRE over-long line fix: http://git.savannah.gnu.org/cgit/grep.git/commit/?id=4572ea4649d025e51463d48c2d06a1c66134cdb8 Integer overflow issues: http://git.savannah.gnu.org/cgit/grep.git/commit/?id=8fcf61523644df42e1905c81bed26838e0b04f91 Paul, are any security issues fixed with those patches? Did I overlook any other patches that need CVE numbers? Thanks 1: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1091473 2: http://lists.gnu.org/archive/html/bug-grep/2012-12/msg00004.html