linux-ext4 - Re: [RFC][PATCH v4 04/09] ext2: use common file type conversion

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 22 Nov 2018 14:47:39 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Phillip Potter <phil@...lpotter.co.uk>, Jan Kara <jack@...e.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Ext4 <linux-ext4@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC][PATCH v4 04/09] ext2: use common file type conversion

On Thu, Nov 22, 2018 at 1:40 PM Jan Kara <jack@...e.cz> wrote:
>
> On Wed 21-11-18 19:06:53, Phillip Potter wrote:
> > Deduplicate the ext2 file type conversion implementation - file systems
> > that use the same file types as defined by POSIX do not need to define
> > their own versions and can use the common helper functions decared in
> > fs_types.h and implemented in fs_types.c
> >
> > Signed-off-by: Amir Goldstein <amir73il@...il.com>
> > Signed-off-by: Phillip Potter <phil@...lpotter.co.uk>
>
> Looks good. You can add:
>
> Reviewed-by: Jan Kara <jack@...e.cz>

Jan,

As you know, Al probably has bigger fish to fry at the moment.
Will you take this patch along with patch #1 through your tree?
Other fs maintainers could apply patches on next cycle (or coordinate
they pull request with you).

If you would agree to that, I suggest to copy the following section
from the cover letter into the ext2 patch:

The current implementation has a lurking out-of-bounds access
bug to the ext2_type_by_mode array.
The array is defined with size S_IFMT >> S_SHIFT, so 15.
This means that it is possible with a malformed inode to
get an index of 15, as the array is always accessed with:
ext2_type_by_mode[(mode & S_IFMT)>>S_SHIFT];

Thanks,
Amir.