Re: Exploit in grep..

[Jaroslav Skarvada]

----- Original Message -----
> Jim Meyering wrote:
> 
> > Jim Meyering wrote:
> >> Joshua Rogers wrote:
> >>> Is this the right place to report a memory corruption
> >>> vulnerability in grep?
> >>
> >> Thanks for asking.
> >> Please be sure you're using the latest from git:
> >>
> >>     http://git.sv.gnu.org/cgit/grep.git
> >>
> >> If you think it may really be exploitable (as in arbitrary code
> >> execution),
> >> it's best not to publicize it right away.  Instead, report it
> >> privately to
> >> a few of the recent committers -- you can use the addresses from
> >> the git log.
> >>
> >> Otherwise, this list is fine.
> >
> > For the record, the problem Joshua noticed is that
> > any input with a matching line longer than ~2GiB
> > would provoke a segfault in grep prior to version 2.11, e.g.,
> >
> >     perl -e 'print "a"x(2**31)' | grep x > /dev/null
> 
> That didn't trigger the problem, due to a typo (no match).
> This does:
> 
>       perl -e 'print "A"x(2**31)' | grep A > /dev/null
> 

Hi,

for older distros, that cannot easily rebase to the latest grep,
could you approve the following workaround?

diff -up grep-2.6.3/src/main.c.orig grep-2.6.3/src/main.c
--- grep-2.6.3/src/main.c.orig  2013-01-24 10:01:14.000000000 +0100
+++ grep-2.6.3/src/main.c       2013-01-24 10:06:11.040824147 +0100
@@ -479,6 +479,10 @@ fillbuf (size_t save, struct stats const
   int cc = 1;
   char *readbuf;
   size_t readsize;
+  const size_t max_save = INT_MAX / 2;
+
+  if (save > max_save)
+    error (2, 0, _("line too long"));

   /* Offset from start of buffer to start of old stuff
      that we want to save.  */

thanks & regards

Jaroslav