From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: "yebin (H)" <yebin10@huawei.com>, Ye Bin <yebin@huaweicloud.com>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+4d99a966fd74bdeeec36@syzkaller.appspotmail.com
Subject: Re: [PATCH] ext4: fix WARNING in ext4_expand_extra_isize_ea
Date: Thu, 1 Dec 2022 10:56:47 -0500 [thread overview]
Message-ID: <Y4jOv26+x8o1MKgC@mit.edu> (raw)
In-Reply-To: <20221201142143.yuxnld55qot4jv7b@quack3>
On Thu, Dec 01, 2022 at 03:21:43PM +0100, Jan Kara wrote:
>
> You're right that VFS actually limits xattr size to 64k. So the chances
> that someone actually has filesystem with larger xattrs are slim. But I
> know that Lustre guys run with their modified kernels and they were the
> ones implementing ea_inode feature so maybe they'd bumped the VFS limit as
> well in their kernels. Dunno. Anyway using kvmalloc() (like the xattr core
> does) looks like a better fix.
I looked at this syzkaller report last night, and note that this was
trying to move an extended attribute from the inode to an external
inode block. Since it was in the inode, the largest the extended
attribute should is going to be the inode size minus 140, plus or
minus.
So the real problem is that the xattr value size was completely
invalid, and we weren't checking the extended attribute before trying
to call ext4_xattr_move_to_block() or ext4_xattr_make_inode_space().
Cheers,
- Ted
next prev parent reply other threads:[~2022-12-01 15:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 8:48 [PATCH] ext4: fix WARNING in ext4_expand_extra_isize_ea Ye Bin
2022-12-01 12:19 ` Jan Kara
2022-12-01 13:25 ` yebin (H)
2022-12-01 14:21 ` Jan Kara
2022-12-01 15:56 ` Theodore Ts'o [this message]
2022-12-01 18:43 ` Eric Biggers
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=Y4jOv26+x8o1MKgC@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+4d99a966fd74bdeeec36@syzkaller.appspotmail.com \
--cc=yebin10@huawei.com \
--cc=yebin@huaweicloud.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