[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] hardlink(1) has buffer overflows, is unsafe on
From:       Huzaifa Sidhpurwala <huzaifas () redhat ! com>
Date:       2011-10-24 4:44:46
Message-ID: 4EA4EA6E.7020100 () redhat ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]