[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EA4EA6E.7020100@redhat.com>
Date: Mon, 24 Oct 2011 10:02:46 +0530
From: Huzaifa Sidhpurwala <huzaifas@...hat.com>
To: oss-security@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Subject: Re: hardlink(1) has buffer overflows, is unsafe on
changing trees
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
