linux-ext4 - Re: [PATCH] ext4: fix WARNING in ext4_expand_extra_isize

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 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, 1 Dec 2022 10:56:47 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     "yebin (H)" <yebin10@...wei.com>, Ye Bin <yebin@...weicloud.com>,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        syzbot+4d99a966fd74bdeeec36@...kaller.appspotmail.com
Subject: Re: [PATCH] ext4: fix WARNING in ext4_expand_extra_isize_ea

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