Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 21 Apr 2023 10:44:31 +0200
From:   Jan Kara <jack@suse.cz>
To:     syzbot <syzbot+1966db24521e5f6e23f7@syzkaller.appspotmail.com>
Cc:     adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com, tytso@mit.edu
Subject: Re: [syzbot] [ext4?] KASAN: slab-out-of-bounds Read in
 get_max_inline_xattr_value_size
Message-ID: <20230421084431.ynek7epoy3mceecr@quack3>
References: <000000000000cdfab505f819529a@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000000000000cdfab505f819529a@google.com>
Precedence: bulk

On Thu 30-03-23 00:48:50, syzbot wrote:
> HEAD commit:    da8e7da11e4b Merge tag 'nfsd-6.3-4' of git://git.kernel.or..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=114fae51c80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=acdb62bf488a8fe5
> dashboard link: https://syzkaller.appspot.com/bug?extid=1966db24521e5f6e23f7
> compiler:       Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1597fd0ec80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14149471c80000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/62e9c5f4bead/disk-da8e7da1.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c11aa933e2a7/vmlinux-da8e7da1.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/7a21bdd49c84/bzImage-da8e7da1.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/58216d4aadcf/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+1966db24521e5f6e23f7@syzkaller.appspotmail.com
> 
> EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
> EXT4-fs error (device loop0): ext4_xattr_ibody_get:669: inode #18: comm syz-executor366: corrupted in-inode xattr: bad magic number in in-inode xattr
> ==================================================================
> BUG: KASAN: slab-use-after-free in get_max_inline_xattr_value_size+0x369/0x510 fs/ext4/inline.c:62
> Read of size 4 at addr ffff88807c4ac084 by task syz-executor366/5076
> 
> CPU: 0 PID: 5076 Comm: syz-executor366 Not tainted 6.3.0-rc3-syzkaller-00338-gda8e7da11e4b #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
>  print_address_description mm/kasan/report.c:319 [inline]
>  print_report+0x163/0x540 mm/kasan/report.c:430
>  kasan_report+0x176/0x1b0 mm/kasan/report.c:536
>  get_max_inline_xattr_value_size+0x369/0x510 fs/ext4/inline.c:62
>  ext4_get_max_inline_size+0x141/0x200 fs/ext4/inline.c:113
>  ext4_prepare_inline_data+0x87/0x1d0 fs/ext4/inline.c:393
>  ext4_da_write_inline_data_begin+0x208/0xe40 fs/ext4/inline.c:931
>  ext4_da_write_begin+0x4da/0x960 fs/ext4/inode.c:3064
>  generic_perform_write+0x300/0x5e0 mm/filemap.c:3926
>  ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:289
>  ext4_file_write_iter+0x1d6/0x1930
>  call_write_iter include/linux/fs.h:1851 [inline]
>  new_sync_write fs/read_write.c:491 [inline]
>  vfs_write+0x7b2/0xbb0 fs/read_write.c:584
>  ksys_write+0x1a0/0x2c0 fs/read_write.c:637
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd

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()?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR