[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZF6vgw+DUP7/orzj@mit.edu>
Date: Fri, 12 May 2023 17:28:35 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Jan Kara <jack@...e.cz>
Cc: syzbot <syzbot+1966db24521e5f6e23f7@...kaller.appspotmail.com>,
adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] KASAN: slab-out-of-bounds Read in
get_max_inline_xattr_value_size
On Fri, Apr 21, 2023 at 10:44:31AM +0200, Jan Kara wrote:
> The problem seems to be that get_max_inline_xattr_value_size() is iterating
> xattr space like:
>
> for (; !IS_LAST_ENTRY(entry); entry = EXT4_XATTR_NEXT(entry)) {
> if (!entry->e_value_inum && entry->e_value_size) {
> size_t offs = le16_to_cpu(entry->e_value_offs);
> if (offs < min_offs)
> min_offs = offs;
> }
> }
>
> without checking for validity of the structures and we can reach this path
> without verifying xattrs are valid. Perhaps we should verify in-inode xattr
> data as part for __ext4_iget()?
We do check that the xattrs are valid when the inline file is opened,
and we would reject the open in that case, so the write system call
would never be able to operate on the corrupted inode.... except when
the reproducer has opened the block device and starts scribbling on
the inode table.
The only way we can stop this particular out-of-bounds read is to add
bounds checking in the above loop. Patch follows (which has been
tested by syzbot).
- Ted
Powered by blists - more mailing lists