linux-ext4 - Re: Mixup with name_len & file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130307182444.GA21237@quack.suse.cz>
Date:	Thu, 7 Mar 2013 19:24:44 +0100
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: Mixup with name_len & file_type in e2fsprogs

On Tue 05-03-13 19:41:38, Jan Kara wrote:
> On Tue 05-03-13 13:29:46, Ted Tso wrote:
> > On Tue, Mar 05, 2013 at 01:18:56PM +0100, Jan Kara wrote:
> > >   Hello,
> > > 
> > >   I was looking into a bug where application using e2fslib was complaining
> > > about file_type > 7. Now the problem is that this is on big endian system
> > > and ext2fs_dir_iterate() ends up calling ext2fs_dirent_swab_in() without
> > > EXT2_DIRBLOCK_V2_STRUCT flag set so name_len is treated as 2 byte and
> > > swapped.
> > 
> > Well, the application most be passing a pointer to treating a pointer
> > to a struct ext2_dir_entry as a struct dir_entry_2, right?  So it's
> > technically doing something wrong it sounds like.
>   Yes, that is correct. Although it is easy to think along the lines of
> "I know the dirents are in v2 format but there's no way to iterate over a
> directory and get v2 dirent so I will just cast the v1 argument." And
> although that is wrong as you point out I did that myself a few times
> because I didn't know a better way.
>  
> > The ext2_dir_entry_2 was probably a mistake, and it's hardly used at
> > all in e2fsprogs.  I wonder if we would be better off not trying to
> > support it at all, and perhaps adding better accessor functions for
> > struct ext2_dir_entry instead.
>   Yeah, that sounds like an easier solution. I'll write a patch for that.
> Thanks for the idea.
  I was thinking some more about it. Won't it be cleaner (and not much
harder) if we always used ext2_dir_entry_2 in e2fsprogs and properly did
byte swapping of name_len only if FILETYPE feature isn't enabled? I've
checked and it would mean changing prototypes of like 8 functions in
ext2fs.h (or better provide new functions with struct ext2_dir_entry_2
argument) which doesn't seem too bad... This solution seems to be the least
surprising to the users of libext2fs (esp. if they do some scanning of
directory blocks themselves or so).

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html