bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #20751] memory corruption in lib/listfile.c can cause segfault


From: anonymous
Subject: [bug #20751] memory corruption in lib/listfile.c can cause segfault
Date: Sat, 11 Aug 2007 06:30:30 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

URL:
  <http://savannah.gnu.org/bugs/?20751>

                 Summary: memory corruption in lib/listfile.c can cause
segfault
                 Project: findutils
            Submitted by: None
            Submitted on: Saturday 08/11/2007 at 06:30 UTC
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Nigel Stepp
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.3.8
           Fixed Release: None

    _______________________________________________________

Details:

I ran into this running 'find /etc -xdev -name amanda -ls' which resulted in
a SIGSEGV.

The problem starts in find/pred.c:pred_ls().
pred_ls() calls pred_fls() with a (struct predicate *)p argument.

Meanwhile....
At lib/listfile.c:203 a string is defined:
  char modebuf[11];

then strmode is called with modebuf as an argument.

At gnulib/lib/filemode.c:181 in strmode we have:
  str[11] = '\0'; /* str is modebuf */

This writes a null just after modebuf...

...*which* happens to be where the low byte of that (struct predicate *)p was
stored on the stack!

So, when list_file returns and pops the address of p off of the stack, it has
now shifted.  In my case, p->perf.successes now actually points to
p->pred_func and in find/util.c:apply_predicate():

      ++(p->perf.successes);

increments p->pred_func and changes pred_ls() to pred_ls+1().

That one instruction at the beginning of pred_ls() is responsible for proper
alignment of the arguments, so when pred_ls() gets called again, it's p
argument is pointing to the wrong place.

It *finally* dies when p->args.printf_vec.stream is 0x0 and gets passed to
fprintf, where you get your SIGSEGV.

To reproduce, configure with:
CFLAGS="-march=pentium3 -O2 -pipe -g" ./configure --without-included-regex
--disable-nls





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?20751>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]