linux-ext4 - Re: [PATCH V2] ext4: don't complain about incorrect features when probing

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]

Message-ID: <1520010408.4790.2.camel@infinera.com>
Date:   Fri, 2 Mar 2018 17:06:50 +0000
From:   Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "sandeen@...hat.com" <sandeen@...hat.com>
Subject: Re: [PATCH V2] ext4: don't complain about incorrect features when
 probing

On Fri, 2018-03-02 at 10:51 -0600, Eric Sandeen wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> If mount is auto-probing for filesystem type, it will try various
> filesystems in order, with the MS_SILENT flag set.  We get
> that flag as the silent arg to ext4_fill_super.
> 
> If we're probing (silent==1) then don't complain about feature
> incompatibilities that are found if it looks like it's actually
> a different valid extN type - failed probes should be silent
> in this case.
> 
> If the on-disk features are unknown even to ext4, then complain.
> 
> Reported-by: Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
> Signed-off-by: Eric Sandeen <sandeen@...hat.com>
> ---
> 
> compile-tested only, sorry.
> 
> V2.  I lied.  (actually I hand-edited the patch in mail)  /Now/ it's compile tested,
> with the proper args to ext4_feature_set_ok :/
> 
> Having 2 gotos like this might not be preferable, but trying
> to write it more compactly led to what I thought was more
> difficult-to-read logic.

Did a quick & dirty backport to 4.14.12 and tested and it works.
(yes, I noticed the error too :)

Thanks

Would be nice if sent to stable as well.

Tested-by: Joakim Tjernlund <Joakim.Tjernlund@...inera.com>

> 
> 
> 
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index b0915b7..ae40368 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3659,6 +3659,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>                         ext4_msg(sb, KERN_INFO, "mounting ext2 file system "
>                                  "using the ext4 subsystem");
>                 else {
> +                       /*
> +                        * If we're probing be silent, if this looks like
> +                        * it's actually an ext[34] filesystem.
> +                        */
> +                       if (silent && ext4_feature_set_ok(sb, sb_rdonly(sb)))
> +                               goto failed_mount;
>                         ext4_msg(sb, KERN_ERR, "couldn't mount as ext2 due "
>                                  "to feature incompatibilities");
>                         goto failed_mount;
> @@ -3670,6 +3676,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>                         ext4_msg(sb, KERN_INFO, "mounting ext3 file system "
>                                  "using the ext4 subsystem");
>                 else {
> +                       /*
> +                        * If we're probing be silent, if this looks like
> +                        * it's actually an ext4 filesystem.
> +                        */
> +                       if (silent && ext4_feature_set_ok(sb, sb_rdonly(sb)))
> +                               goto failed_mount;
>                         ext4_msg(sb, KERN_ERR, "couldn't mount as ext3 due "
>                                  "to feature incompatibilities");
>                         goto failed_mount;
> 
>