From: Vlastimil Babka <vbabka@suse.cz>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzbot <syzbot+2a1797e8845b57b4a3c2@syzkaller.appspotmail.com>,
syzkaller-bugs@googlegroups.com, linux-mm <linux-mm@kvack.org>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [syzbot] riscv/fixes boot error: BUG: unable to handle kernel NULL pointer dereference in corrupted
Date: Tue, 14 Sep 2021 15:04:17 +0200 [thread overview]
Message-ID: <bf8b363d-d1a9-212c-ef6f-6292a9a133b5@suse.cz> (raw)
In-Reply-To: <c31d6ece-2cf2-f303-f02f-169d79db2676@i-love.sakura.ne.jp>
On 9/14/21 12:55, Tetsuo Handa wrote:
> Hmm, I feel that something is wrong with slub... Any idea?
Weird.
> #syz dup: BUG: unable to handle kernel paging request in tomoyo_encode2
>
> On 2021/09/14 19:39, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 7d2a07b76933 Linux 5.14
>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
>> console output: https://syzkaller.appspot.com/x/log.txt?x=15cb131b300000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=f8211b06020972e8
>> dashboard link: https://syzkaller.appspot.com/bug?extid=2a1797e8845b57b4a3c2
>> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>> userspace arch: riscv64
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+2a1797e8845b57b4a3c2@syzkaller.appspotmail.com
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000d48
>> Oops [#1]
>> Modules linked in:
>> CPU: 1 PID: 2924 Comm: kworker/u4:5 Not tainted 5.14.0-syzkaller #0
>> Hardware name: riscv-virtio,qemu (DT)
>> epc : slab_alloc_node mm/slub.c:2900 [inline]
That's this line:
tid = this_cpu_read(s->cpu_slab->tid);
This would mean something's off with the percpu variable s->cpu_slab.
Looking at the original report:
https://lore.kernel.org/all/000000000000bae2cf05cad87aff@google.com/
That's even more weird, we passed this line but crashed a bit later in
this_cpu_cmpxchg_double() which also accesses s->cpu_slab. Did the "s"
pointer itself get corrupted?
>> epc : slab_alloc mm/slub.c:2967 [inline]
>> epc : __kmalloc+0xce/0x388 mm/slub.c:4111
>> ra : slab_pre_alloc_hook mm/slab.h:494 [inline]
>> ra : slab_alloc_node mm/slub.c:2880 [inline]
>> ra : slab_alloc mm/slub.c:2967 [inline]
>> ra : __kmalloc+0x6e/0x388 mm/slub.c:4111
>> epc : ffffffff803e3568 ra : ffffffff803e3508 sp : ffffffe008c6f780
>> gp : ffffffff83f967d8 tp : ffffffe00b71df00 t0 : ffffffc400b37600
>> t1 : 0000000000000001 t2 : 0000000000000000 s0 : ffffffe008c6f820
>> s1 : ffffffe005601500 a0 : 0000000000000000 a1 : ffffffe008c6fb6c
>> a2 : 1ffffffc016e3d07 a3 : 0000000000000d48 a4 : 0000000000000001
>> a5 : ffffffff82e4b290 a6 : 0000000000f00000 a7 : ffffffff8038ca52
>> s2 : ffffffff83f96adc s3 : 0000000000000d40 s4 : 0000000000000019
>> s5 : ffffffff8080a860 s6 : ffffffff83f9a0d0 s7 : 0000000000000000
>> s8 : 0000000000000d40 s9 : 0000000000000001 s10: ffffffe005aeb6e0
>> s11: 000000000000002f t3 : 4f89673883b77f00 t4 : ffffffc40118df07
>> t5 : ffffffc40118df09 t6 : ffffffe0059baffe
>> status: 0000000000000120 badaddr: 0000000000000d48 cause: 000000000000000d
>> [<ffffffff803e3568>] slab_alloc_node mm/slub.c:2900 [inline]
>> [<ffffffff803e3568>] slab_alloc mm/slub.c:2967 [inline]
>> [<ffffffff803e3568>] __kmalloc+0xce/0x388 mm/slub.c:4111
>> [<ffffffff8080a860>] kmalloc include/linux/slab.h:596 [inline]
>> [<ffffffff8080a860>] kzalloc include/linux/slab.h:721 [inline]
>> [<ffffffff8080a860>] tomoyo_encode2.part.0+0xf0/0x262 security/tomoyo/realpath.c:45
>> [<ffffffff8080abc2>] tomoyo_encode2 security/tomoyo/realpath.c:31 [inline]
>> [<ffffffff8080abc2>] tomoyo_encode security/tomoyo/realpath.c:80 [inline]
>> [<ffffffff8080abc2>] tomoyo_realpath_from_path+0x14c/0x3f4 security/tomoyo/realpath.c:288
>> [<ffffffff807f17e8>] tomoyo_init_log+0x7a2/0x13aa security/tomoyo/audit.c:263
>> [<ffffffff807f9c1e>] tomoyo_supervisor+0x1bc/0xb0c security/tomoyo/common.c:2097
>> [<ffffffff80801ca0>] tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
>> [<ffffffff80801ca0>] tomoyo_env_perm+0x100/0x120 security/tomoyo/environ.c:63
>> [<ffffffff80801798>] tomoyo_environ security/tomoyo/domain.c:672 [inline]
>> [<ffffffff80801798>] tomoyo_find_next_domain+0xd24/0x109a security/tomoyo/domain.c:879
>> [<ffffffff8080c098>] tomoyo_bprm_check_security security/tomoyo/tomoyo.c:101 [inline]
>> [<ffffffff8080c098>] tomoyo_bprm_check_security+0xdc/0x136 security/tomoyo/tomoyo.c:91
>> [<ffffffff807e8b8e>] security_bprm_check+0x44/0x96 security/security.c:866
>> [<ffffffff80438242>] search_binary_handler fs/exec.c:1709 [inline]
>> [<ffffffff80438242>] exec_binprm fs/exec.c:1762 [inline]
>> [<ffffffff80438242>] bprm_execve fs/exec.c:1831 [inline]
>> [<ffffffff80438242>] bprm_execve+0x4ba/0x10a6 fs/exec.c:1793
>> [<ffffffff80439e7c>] kernel_execve+0x204/0x288 fs/exec.c:1974
>> [<ffffffff8005afec>] call_usermodehelper_exec_async+0x1bc/0x2d8 kernel/umh.c:112
>> [<ffffffff8000515e>] ret_from_exception+0x0/0x14
>> ---[ end trace 77235688c0a8656b ]---
>>
>>
>> ---
>> This report is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this issue. See:
>> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>>
>
>
prev parent reply other threads:[~2021-09-14 13:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000000000000c81e6305cbf2319c@google.com>
2021-09-14 10:55 ` Tetsuo Handa
2021-09-14 13:04 ` Vlastimil Babka [this message]
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=bf8b363d-d1a9-212c-ef6f-6292a9a133b5@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+2a1797e8845b57b4a3c2@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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