mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Theodore Ts'o <tytso@mit.edu>,
	syzbot <syzbot+ea70429cd5cf47ba8937@syzkaller.appspotmail.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	nathan@kernel.org, ndesaulniers@google.com,
	syzkaller-bugs@googlegroups.com, trix@redhat.com,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
Date: Mon, 14 Nov 2022 11:21:33 -0500	[thread overview]
Message-ID: <8c3757ae-1aeb-49a4-47af-598d1d4737ea@redhat.com> (raw)
In-Reply-To: <Y3Jb1Wcs/mQlZP32@mit.edu>

On 11/14/22 10:16, Theodore Ts'o wrote:
> +jaeguk,chao,peterz,mingo,longman,boqun.feng (F2FS and Lockdep maintainers)
>
> On Sun, Nov 13, 2022 at 02:55:47PM -0800, syzbot wrote:
>> syzbot has found a reproducer for the following issue on:
>>
>> HEAD commit:    af7a05689189 Merge tag 'mips-fixes_6.1_1' of git://git.ker..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=175bb059880000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=cbbe7c32024f5b72
>> dashboard link: https://syzkaller.appspot.com/bug?extid=ea70429cd5cf47ba8937
>> compiler:       Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10930249880000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11af96ae880000
> This looks like it's either a f2fs or lockdep bug.  To trigger the
> crash, the reproducer is mounting and unmounting the f2fs file system
> a huge number of times, and then ext4 calls lockdep_set_subclass which
> then triggers a KASAN report:
>
> BUG: KASAN: slab-out-of-bounds in lockdep_set_quota_inode fs/ext4/super.c:6803 [inline]
>
> On fs/ext4/super.c:6803 is the call to lockdep_set_subclass:
>
> 	lockdep_set_subclass(&ei->i_data_sem, subclass);
>
> So the KASAN failure is coming from some kind of out-of-bounds pointer
> dereference inside lockdep's internal data structures:
>
>   kasan_report+0xcd/0x100 mm/kasan/report.c:495
>   lockdep_set_quota_inode fs/ext4/super.c:6803 [inline]
>   ext4_quota_enable fs/ext4/super.c:6913 [inline]
>   ext4_enable_quotas+0x577/0xcf0 fs/ext4/super.c:6940
>   __ext4_fill_super fs/ext4/super.c:5500 [inline]
>   ext4_fill_super+0x7ee4/0x8610 fs/ext4/super.c:5643
>   get_tree_bdev+0x400/0x620 fs/super.c:1324
>   vfs_get_tree+0x88/0x270 fs/super.c:1531
>   do_new_mount+0x289/0xad0 fs/namespace.c:3040
>   do_mount fs/namespace.c:3383 [inline]

lockdep_set_subclass() should be translated into a call to 
lockdep_init_map_type():

#define lockdep_set_subclass(lock, sub)                                 \
         lockdep_init_map_type(&(lock)->dep_map, #lock, 
(lock)->dep_map.key, sub,\
(lock)->dep_map.wait_type_inner,          \
(lock)->dep_map.wait_type_outer,          \
                               (lock)->dep_map.lock_type)

All memory access should be within the bound of the given 
"&ei->i_data_sem". Also lockdep_init_map_type() is not in the stack 
trace. So it is not a problem within this lockdep_init_map_type() 
function. So is it possible that the given inode pointer is invalid?

Cheers,
Longman



  reply	other threads:[~2022-11-14 16:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 11:46 syzbot
2022-11-13 22:55 ` syzbot
2022-11-14 15:16   ` Theodore Ts'o
2022-11-14 16:21     ` Waiman Long [this message]
2022-11-14 17:53       ` Theodore Ts'o
2023-07-20 15:17         ` Dmitry Vyukov

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=8c3757ae-1aeb-49a4-47af-598d1d4737ea@redhat.com \
    --to=longman@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=boqun.feng@gmail.com \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=syzbot+ea70429cd5cf47ba8937@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=trix@redhat.com \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®