bugfindutils - Bugs: bug #20751, memory corruption in...

 
 

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

Submitter:  None
Submitted:  Sat 11 Aug 2007 06:30:28 AM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  ericb
Originator Name:  Nigel Stepp Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.28
Fixed Release:  4.3.9
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 23 Jan 2008 07:07:08 PM UTC, comment #3: 


> Present in 4.3.1 through 4.3.8, and in 4.2.28 through 4.2.31.


Are you sure? Afaict the respective gnulib change was applied in 4.2.31, so 4.2.28 to 4.2.30 should be clean.

I think you are right about the 4.3 series, I can verify that 4.3.5 to 4.3.8 have the bug and 4.3.9 is clean.

Andreas Metzler <ametzler>
Sat 11 Aug 2007 01:40:07 PM UTC, comment #2: 

Present in 4.3.1 through 4.3.8, and in 4.2.28 through 4.2.31.

Eric Blake <ericb>
Group administrator
Sat 11 Aug 2007 01:26:00 PM UTC, comment #1: 

I had noticed the problem for a while, but did not realize it could trigger a segfault.  The culprit is this patch in gnulib, documented in line 127 in the diff (from July 2006):

http://cvs.savannah.gnu.org/viewvc/gnulib/lib/filemode.c?root=gnulib&r1=1.16&r2=1.17

I had a patch sitting around on my disk at one point; I'll dig it up and submit it to the findutils-patches list.

Eric Blake <ericb>
Group administrator
Sat 11 Aug 2007 06:30:28 AM UTC, original submission:  

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

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Updated the item)
  • -email is unavailable- added by ericb (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-23 ametzler Carbon-CopyRemoved 20807 -
    2007-11-11 jay Open/ClosedOpen Closed
        Fixed ReleaseNone 4.3.9
    2007-08-18 ericb StatusConfirmed Fixed
    2007-08-11 ericb Release4.3.8 4.2.28
    2007-08-11 ericb StatusNone Confirmed
        Assigned toNone ericb

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code