[Top][All Lists]

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

Re: heap corruption in du

From: Mikulas Patocka
Subject: Re: heap corruption in du
Date: Mon, 10 Oct 2005 23:44:05 +0200 (CEST)

On Mon, 10 Oct 2005, Jim Meyering wrote:

Mikulas Patocka <address@hidden> wrote:
I got this message from du from coreutils 5.2.1:

du: fts_read failed: No such file or directory
*** glibc detected *** corrupted double-linked list: 0x0806c390 ***

I was sometimes able reproduce on an AFS filesystem. It turned out that
AFS filesystem changes inode numbers or device numbers, so
fts_safe_changedir called at the end of fts_read fails. fts_read sets
FTS_STOP, returns NULL and lets fts_cur to point to just freed entry few
lines above (free(tmp)). The next call to fts_close will do a double-free.

This patch fixes the problem in this situation (and other possible
scenarios resulting from various syscalls failing) --- however you should
better go through the whole code for handling of fts tree and check it.

Thanks for the report and patch.
That bug was fixed almost exactly a year ago (see the 1.20->1.21 delta
of fts.c for a slightly different change).

The latest test release is here:

BTW. How stable are alpha versions of GNU software from this server? Do you think they are OK for a production multiuser machine?

Shouldn't new regular non-alpha version be made for these kind of fixes? --- on my server, du runs every night to count users' used space --- if users can corrupt its memory by moving directories around and changing parent's inode number, it can be even a security hole.


Or check it out from CVS:

reply via email to

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