Re: hardlink(1) has buffer overflows, is unsafe on changing trees

[Huzaifa Sidhpurwala <huzaifas () redhat com>]

On 10/22/2011 08:51 AM, Solar Designer wrote:
> I investigated the non-crashing build further.  No, adding more
> directories did not cause a crash either.  What happens is that lstat()
> starts failing with ENAMETOOLONG shortly _after_ the overflow occurs.
> This happens to limit the largest overflow size.  If "dirs" is not yet
> overwritten by this point (was not reached by the overflow), then the
> program may proceed without crashing and without descending to deeper
> directories (thus not overflowing the buffer even further).  So
> different builds may be affected to a different extent, depending on
> relative placement of variables in .bss.  The behavior may also vary by
> kernel version, though (when lstat() starts to fail is a property of the
> kernel, whereas NAMELEN in hardlink.c is fixed).  I am able to make this
> build crash with "*** buffer overflow detected ***" on the strcat(),
> though, by carefully adjusting the directory name lengths (but that's
> relatively uninteresting).

I think this is exactly what i hit, when testing on some Fedora/RHEL 
machines.

Kernel defines the following:
#define PATH_MAX        4096    /* # chars in a path name including nul */

And in the lstat implementation:

     if (dentry->d_name.len > NAME_MAX)
                return ERR_PTR(-ENAMETOOLONG);


--
Huzaifa Sidhpurwala / Red Hat Security Response Team