Re: [reiserfs-list] major security bug in reiserfs (may affect

Vladimir V. Saveliev (vs@namesys.botik.ru)
Wed, 10 Jan 2001 19:29:27 +0300


Chris Mason wrote:

> On Wednesday, January 10, 2001 07:02:08 PM +0300 "Vladimir V. Saveliev"
> <vs@namesys.botik.ru> wrote:
>
> > Hi
> >
> > Chris Mason wrote:
> >
> >> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann
> >> <pcg@goof.com> wrote:
> >>
> >> >>> EIP; c013f911 <filldir+20b/221> <=====
> >> > Trace; c013f706 <filldir+0/221>
> >> > Trace; c0136e01 <reiserfs_getblk+2a/16d>
> >>
> >> The buffer reiserfs is sending to filldir is big enough for
> >> the huge file name, so I think the real fix should be done in VFSland.
> >>
> >> But, in the interest of providing a quick, obviously correct fix, this
> >> reiserfs only patch will refuse to create file names larger
> >> than 255 chars, and skip over any directory entries larger than
> >> 255 chars.
> >>
> >
> > Hmm, wouldn't it make existing long named files unreachable?
> >
>
> Yes, that was intentional. We can make a different version of the patch
> that changes reiserfs_find_entry to allow opening the large filenames for
> delete and such. But, as a quick fix, I wanted to close all possible paths
> to the long names.
>

Sorry, I still do not understand what you are fixing :)

Btw, I do not see how does fs/readdir.c:fillonedir (I am looking at
2.4.0-test10) check that buffer provided by user is long enough to keep the
name in. (that is old_readdir looks broken for me - am I missing something?)
Whereas filldir seems to check whether there is enough space left in the
buffer.

Thanks,
vs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/