linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Baokun Li <libaokun1@huawei.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	wenqingliu0120@gmail.com, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, "zhangyi (F)" <yi.zhang@huawei.com>,
	yebin10@huawei.com, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero
Date: Fri, 12 Aug 2022 10:22:29 +0100	[thread overview]
Message-ID: <YvYb1fgvGmdDRmKd@suse.de> (raw)
In-Reply-To: <e10617e8-1a21-a046-8256-66ffc6500ae9@huawei.com>

On Fri, Aug 12, 2022 at 10:33:20AM +0800, Baokun Li wrote:
> 在 2022/8/5 22:00, Luís Henriques 写道:
...
> > This bug is easily reproducible using the filesystem image provided --
> > it's just a matter of mounting it and run:
> > 
> >      $ cat /mnt/foo/bar/xattr
> 
> Hi Luís,
> yeah, that's a good catch!
> > Anyway, I hope my analysis of the bug is correct -- the root cause seems
> > to be an extent header with an invalid value for in eh_entries, which will
> > later cause the BUG_ON().
> > 
> > Cheers,
> > --
> > Luís
> But there's a little bit of a deviation in your understanding of the
> problem,
> so the patch doesn't look good.
> The issue is caused by the contradiction between eh_entries and eh_depth.

Ah! This makes a lot of sense and I can confirm this is exactly what
happens in both bugzilla images.  Thanks a lot for your feedback!

> Therefore, we need to check the contradiction instead of adding a judgment
> to ext4_ext_binsearch_idx.
> So the right fix is to add a check to __ext4_ext_check like:
> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index c148bb97b527..2dfd35f727cb 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -460,6 +460,10 @@ static int __ext4_ext_check(const char *function,
> unsigned int line,
>                 error_msg = "invalid eh_entries";
>                 goto corrupted;
>         }
> +       if (unlikely((eh->eh_entries == 0) && (depth > 0))) {
> +               error_msg = "contradictory eh_entries and eh_depth";
> +               goto corrupted;
> +       }
>         if (!ext4_valid_extent_entries(inode, eh, lblk, &pblk, depth)) {
>                 error_msg = "invalid extent entries";
>                 goto corrupted;
> 
> In this way, we can fix this issue and check for header exceptions before
> calling ext4_ext_binsearch_idx.

Awesome, I'll send out v2 with the suggested change.  It makes sense to
have this check and it should fix both bugs.

On the other hand, I still wonder wether the extra check in my original
patch is correct or not.  I spent a good amount of time trying to find out
if eh_entries can be 0 at that point (in ext4_ext_binsearch_idx()) and
couldn't find a situation where it could.  And running the fstests with
that check didn't show any problem.  But yeah, my understanding of the
whole code is far from perfect.

Cheers,
--
Luís

  reply	other threads:[~2022-08-12  9:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04 19:42 [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon
2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques
2022-08-11 17:24   ` Luís Henriques
2022-08-12  2:33   ` Baokun Li
2022-08-12  9:22     ` Luís Henriques [this message]
2022-10-04  9:14 ` [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon
2022-10-04 19:48 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvYb1fgvGmdDRmKd@suse.de \
    --to=lhenriques@suse.de \
    --cc=adilger.kernel@dilger.ca \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=wenqingliu0120@gmail.com \
    --cc=yebin10@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).