From: Qianqiang Liu <qianqiang.liu@163.com>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
syzbot <syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ext4: fix out-of-bounds issue in ext4_xattr_set_entry
Date: Wed, 2 Oct 2024 14:27:59 +0800 [thread overview]
Message-ID: <Zvzn73lrBnVrwNp5@fedora> (raw)
In-Reply-To: <ZvvD2FeVm3ViPWIl@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Hi Ojaswin,
On Tue, Oct 01, 2024 at 03:11:44PM +0530, Ojaswin Mujoo wrote:
>
> Hey Qianqiang,
>
> Thanks for the patch. I'm still reviewing this codepath but I do have
> some questions around the patch. So I understand that xattrs are
> arranged in the following format:
>
> * +------------------+
> * | header |
> * | entry 1 |
> * | entry 2 |
> * | entry 3 |
> * | four null bytes | <--- last
> * | . . . |
> * | . . . | <--- here
> * | . . . |
> * | value 1 |
> * | value 3 |
> * | value 2 |
> * +------------------+
>
> Now, in this error, my understanding is that we are actually ending up
> in a case where "here" ie the place where the new xattr entry will go is
> beyond the "last" ie the last slot for xattr entry and that is causing
> an underflow, something like the above diagram.
>
> My only concern is that why were we not able to detect this in the logic
> near the start of the function where we explcity check if we have enough
> space?
>
> Perhaps we should be fixing the logic in that if {..} instead
> since the comment a few lines above your fix:
>
> /* No failures allowed past this point. */
>
> does suggest that we can't error out below that point, so ideally all
> the checks would have been done before that.
>
> I'm still going through the issue, will update here if needed.
>
> Regards,
> ojaswin
>
I reviewed the codepath, and here is the backtrace when the error occurs:
=> vfs_unlink
=> ext4_unlink
=> __ext4_unlink
=> __ext4_mark_inode_dirty
=> ext4_try_to_expand_extra_isize
=> __ext4_expand_extra_isize
=> ext4_expand_extra_isize_ea
=> ext4_xattr_make_inode_space
=> ext4_xattr_move_to_block -> ext4_xattr_block_find -> xattr_find_entry
=> ext4_xattr_block_set
=> ext4_xattr_set_entry
=> memmove((void *)here + size, here, rest);
The xattr_find_entry function return -ENODATA, but beacuase of the
following code, the error does not be returned to caller:
static int
ext4_xattr_block_find(struct inode *inode, struct ext4_xattr_info *i,
struct ext4_xattr_block_find *bs)
{
...
error = xattr_find_entry(inode, &bs->s.here, bs->s.end,
i->name_index, i->name, 1);
if (error && error != -ENODATA)
return error;
...
}
So, perhaps we could modify the code as follows:
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index e0e1956dcdd3..649b278d4c1f 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1884,7 +1884,7 @@ ext4_xattr_block_find(struct inode *inode, struct ext4_xattr_info *i,
bs->s.here = bs->s.first;
error = xattr_find_entry(inode, &bs->s.here, bs->s.end,
i->name_index, i->name, 1);
- if (error && error != -ENODATA)
+ if (error)
return error;
bs->s.not_found = error;
}
Or, we could check if s->not_found is -ENODATA in the ext4_xattr_set_entry function.
Any suggestions?
--
Best,
Qianqiang Liu
next prev parent reply other threads:[~2024-10-02 6:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 0:16 [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry syzbot
2024-09-22 5:46 ` Qianqiang Liu
2024-09-22 6:35 ` syzbot
2024-09-22 6:42 ` [PATCH] ext4: fix out-of-bounds issue " Qianqiang Liu
2024-10-01 9:41 ` Ojaswin Mujoo
2024-10-01 10:15 ` Qianqiang Liu
2024-10-02 6:27 ` Qianqiang Liu [this message]
2024-10-08 7:40 ` Baokun Li
2024-10-09 15:50 ` Jan Kara
2024-10-11 2:18 ` Baokun Li
2024-10-14 16:31 ` Jan Kara
2024-10-16 8:02 ` Baokun Li
2024-10-16 20:47 ` Theodore Ts'o
2024-10-17 12:42 ` Baokun Li
2024-10-17 14:47 ` Theodore Ts'o
2024-10-18 3:44 ` Baokun Li
2024-10-02 6:31 ` [syzbot] [ext4?] KASAN: out-of-bounds Read " Qianqiang Liu
2024-10-02 6:54 ` syzbot
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=Zvzn73lrBnVrwNp5@fedora \
--to=qianqiang.liu@163.com \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.