On Tue 08-10-24 15:40:39, Baokun Li wrote:
> On 2024/9/22 14:42, Qianqiang Liu wrote:
> > syzbot has found an out-of-bounds issue in ext4_xattr_set_entry:
> >
> > ==================================================================
> > BUG: KASAN: out-of-bounds in ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
> > Read of size 18446744073709551572 at addr ffff888036426850 by task syz-executor264/5095
> >
> > CPU: 0 UID: 0 PID: 5095 Comm: syz-executor264 Not tainted 6.11.0-syzkaller-03917-ga940d9a43e62 #0
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> > Call Trace:
> > <TASK>
> > __dump_stack lib/dump_stack.c:93 [inline]
> > dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
> > print_address_description mm/kasan/report.c:377 [inline]
> > print_report+0x169/0x550 mm/kasan/report.c:488
> > kasan_report+0x143/0x180 mm/kasan/report.c:601
> > kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
> > __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
> > ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
> > [...]
> > ==================================================================
> >
> > This issue is caused by a negative size in memmove.
> > We need to check for this.
> >
> > Fixes: dec214d00e0d ("ext4: xattr inode deduplication")
> > Reported-by: syzbot+f792df426ff0f5ceb8d1@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> > Tested-by: syzbot+f792df426ff0f5ceb8d1@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Signed-off-by: Qianqiang Liu <qianqiang.liu@xxxxxxx>
> > ---
> > fs/ext4/xattr.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> > index 46ce2f21fef9..336badb46246 100644
> > --- a/fs/ext4/xattr.c
> > +++ b/fs/ext4/xattr.c
> > @@ -1776,7 +1776,14 @@ static int ext4_xattr_set_entry(struct ext4_xattr_info *i,
> > } else if (s->not_found) {
> > /* Insert new name. */
> > size_t size = EXT4_XATTR_LEN(name_len);
> > - size_t rest = (void *)last - (void *)here + sizeof(__u32);
> > + size_t rest;
> > +
> > + if (last < here) {
> > + ret = -ENOSPC;
> > + goto out;
> > + } else {
> > + rest = (void *)last - (void *)here + sizeof(__u32);
> > + }
> > memmove((void *)here + size, here, rest);
> > memset(here, 0, size);
> This change just passes syzbot's test cases without fixing the real
> problem.
>
> The root cause of the problem is that the inode's xattr block is marked as
> free in the block bitmap, so that block is allocated to the ea inode
> resulting in the data in the xattr block being overwritten, and the last of
> the second lookups changing resulting in out-of-bounds access.
>
> The stack that triggers the problem is as follows:
>
> // An inode with an xattr block of 33.
> __ext4_mark_inode_dirty
> __ext4_expand_extra_isize
> ext4_expand_extra_isize_ea
> ext4_xattr_make_inode_space
> // Move xattr from inode to block
> ext4_xattr_move_to_block
> // Find out if the xattr exists in the block
> ext4_xattr_block_find
> // If xattr does not exist, here == last
> xattr_find_entry
> // Add a new xattr to the block
> ext4_xattr_block_set
> |// xattr is too long, needs an ea inode
> |ext4_xattr_inode_lookup_create
> | ext4_xattr_inode_create
> | ext4_xattr_inode_write
> | ext4_map_blocks
> | // xattr block 33 is assigned to the new ea inode
> | memcpy(bh->b_data, buf, csize)
> | // The value of xattr overwrites the data in the xattr block.
> |ext4_xattr_set_entry
> // Since the contents of the xattr block have changed,
> // now here == last does not hold, so it is possible to
> // have last < here and trigger an out-of-bounds access.
>
> So I think we should probably add a helper function ext4_mb_block_inuse()
> that checks if xattr block is free with the block bitmap in check_xattrs().
Well, even that would be a relatively narrow fix. You could have e.g.
file reference the xattr block as one of its data blocks and then corrupt
xattr contents at unfortunate moment. That will not get fixed by checking
whether the block is allocated. These multiply claimed blocks (as e2fsck
calls it) are very hard to detect inside the kernel.
> Or go one step further and add a mechanism like xfs Reverse-Mapping, which
> makes sure that allocated blocks do point to the target inode, which could
> replace the current block_validity, and could also be used in future online
> fscks.
Well, that is a rather big change. It requires significant on-disk format
change and also performance cost when to maintain. Furthermore for xattr
blocks which can be shared by many inodes it is not even clear how to
implement this... So I'm not sure we really want to do this either.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
