* [syzbot] [bpf?] WARNING in push_jmp_history @ 2024-10-07 18:35 syzbot 2024-10-07 22:18 ` Eduard Zingerman 2024-10-08 8:43 ` syzbot 0 siblings, 2 replies; 5+ messages in thread From: syzbot @ 2024-10-07 18:35 UTC (permalink / raw) To: andrii, ast, bpf, daniel, eddyz87, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song Hello, syzbot found the following issue on: HEAD commit: c02d24a5af66 Add linux-next specific files for 20241003 git tree: linux-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=17382707980000 kernel config: https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d dashboard link: https://syzkaller.appspot.com/bug?extid=7e46cdef14bf496a3ab4 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b82707980000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f4c327980000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/641e642c9432/disk-c02d24a5.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/98aaf20c29e0/vmlinux-c02d24a5.xz kernel image: https://storage.googleapis.com/syzbot-assets/c23099f2d86b/bzImage-c02d24a5.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7e46cdef14bf496a3ab4@syzkaller.appspotmail.com ------------[ cut here ]------------ virt_to_cache: Object is not a Slab page! WARNING: CPU: 0 PID: 5232 at mm/slub.c:4655 virt_to_cache mm/slub.c:4655 [inline] WARNING: CPU: 0 PID: 5232 at mm/slub.c:4655 __do_krealloc mm/slub.c:4753 [inline] WARNING: CPU: 0 PID: 5232 at mm/slub.c:4655 krealloc_noprof+0x1b3/0x2e0 mm/slub.c:4838 Modules linked in: CPU: 0 UID: 0 PID: 5232 Comm: syz-executor250 Not tainted 6.12.0-rc1-next-20241003-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:virt_to_cache mm/slub.c:4655 [inline] RIP: 0010:__do_krealloc mm/slub.c:4753 [inline] RIP: 0010:krealloc_noprof+0x1b3/0x2e0 mm/slub.c:4838 Code: 45 31 ff 45 31 f6 45 31 ed e9 21 ff ff ff c6 05 4e 2a 14 0e 01 90 48 c7 c7 24 f2 0b 8e 48 c7 c6 44 f2 0b 8e e8 3e 19 63 ff 90 <0f> 0b 90 90 e9 d9 fe ff ff f3 0f 1e fa 41 8b 45 08 f7 d0 a8 88 0f RSP: 0018:ffffc90003c36ba8 EFLAGS: 00010246 RAX: 3f2bb101b90db800 RBX: 0000000000000000 RCX: ffff88802bb01e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88807849c000 R08: ffffffff8155d412 R09: 1ffff110170c519a R10: dffffc0000000000 R11: ffffed10170c519b R12: 0000000000004000 R13: 0000000000000201 R14: 0000000000100cc0 R15: dffffc0000000000 FS: 0000555587952380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005594dac5c5d8 CR3: 00000000786d6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> push_jmp_history+0x13c/0x5c0 kernel/bpf/verifier.c:3497 do_check+0x6716/0xfe40 kernel/bpf/verifier.c:18352 do_check_common+0x14bd/0x1dd0 kernel/bpf/verifier.c:21618 do_check_main kernel/bpf/verifier.c:21709 [inline] bpf_check+0x18a25/0x1e320 kernel/bpf/verifier.c:22421 bpf_prog_load+0x1667/0x20f0 kernel/bpf/syscall.c:2846 __sys_bpf+0x4ee/0x810 kernel/bpf/syscall.c:5634 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline] __se_sys_bpf kernel/bpf/syscall.c:5739 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5739 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc05a9603e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd106d44d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 00007ffd106d46b8 RCX: 00007fc05a9603e9 RDX: 0000000000000048 RSI: 00000000200054c0 RDI: 0000000000000005 RBP: 00007fc05a9d4610 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffd106d46a8 R14: 0000000000000001 R15: 0000000000000001 </TASK> --- 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. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [bpf?] WARNING in push_jmp_history 2024-10-07 18:35 [syzbot] [bpf?] WARNING in push_jmp_history syzbot @ 2024-10-07 22:18 ` Eduard Zingerman 2024-10-08 8:43 ` syzbot 1 sibling, 0 replies; 5+ messages in thread From: Eduard Zingerman @ 2024-10-07 22:18 UTC (permalink / raw) To: syzbot, andrii, ast, bpf, daniel, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song On Mon, 2024-10-07 at 11:35 -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: c02d24a5af66 Add linux-next specific files for 20241003 > git tree: linux-next > console+strace: https://syzkaller.appspot.com/x/log.txt?x=17382707980000 > kernel config: https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d > dashboard link: https://syzkaller.appspot.com/bug?extid=7e46cdef14bf496a3ab4 > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b82707980000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f4c327980000 When I try this reproducer the bpf syscall never exits (waited for 5 minutes). Here is the reproducer as a selftest: SEC("kprobe") __success __naked void syzbot_bug(void) { asm volatile ( " r2 = *(u32 *)(r1 +140)\n" // 0 " r3 = *(u32 *)(r1 +76)\n" // 1 " r0 = r2\n" // 2 " if w0 > 0xffffff07 goto 1f\n" // 3 " if r3 <= r0 goto +16\n" // 4 " exit\n" // 5 "1: r6 = *(u16 *)(r1 +0)\n" // 6 " r7 = r6\n" // 7 "2: w7 += 447767737\n" // 8 " if w7 & 0x702000 goto 2b\n" // 9 " w7 &= 2024974\n" // 10 " r5 = r1\n" // 11 " r7 += r5\n" // 12 " if r7 s> 0x37d2 goto +0\n" // 13 " w3 *= w0\n" // 14 " r5 -= r7\n" // 15 " r4 = r5\n" // 16 " r0 += -458748\n" // 17 " if r3 < r4 goto 3f\n" // 18 " w0 >>= w0\n" // 19 "3: goto +0\n" // 20 " exit\n" // 21 ::: __clobber_all); } (e.g. can be put to tools/testing/selftests/bpf/progs/verifier_and.c or any other verifier_*.c). Inserting a few printks shows that the following instructions are verified in a loop: ... verification starts ... [ 2.094272] do_check: env->insn_idx 0 [ 2.094345] do_check: env->insn_idx 1 [ 2.094417] do_check: env->insn_idx 2 [ 2.094486] do_check: env->insn_idx 3 [ 2.094585] do_check: env->insn_idx 4 [ 2.094675] do_check: env->insn_idx 5 [ 2.094748] do_check: env->insn_idx 21 [ 2.094879] do_check: env->insn_idx 6 [ 2.095005] do_check: env->insn_idx 7 [ 2.095074] do_check: env->insn_idx 8 <------ let's call this point LBL [ 2.095156] do_check: env->insn_idx 9 [ 2.095264] do_check: env->insn_idx 8 [ 2.095372] do_check: env->insn_idx 9 [ 2.095497] do_check: env->insn_idx 8 [ 2.095579] do_check: env->insn_idx 9 [ 2.095716] do_check: env->insn_idx 8 [ 2.095892] do_check: env->insn_idx 9 [ 2.096070] do_check: env->insn_idx 8 [ 2.096151] do_check: env->insn_idx 9 [ 2.096314] do_check: env->insn_idx 8 [ 2.096402] do_check: env->insn_idx 9 [ 2.096570] do_check: env->insn_idx 8 [ 2.096646] do_check: env->insn_idx 9 [ 2.096840] do_check: env->insn_idx 8 [ 2.096921] do_check: env->insn_idx 9 [ 2.097040] do_check: env->insn_idx 10 [ 2.097113] do_check: env->insn_idx 11 [ 2.097195] do_check: env->insn_idx 12 [ 2.097417] do_check: env->insn_idx 13 [ 2.097521] do_check: env->insn_idx 14 [ 2.097597] do_check: env->insn_idx 15 [ 2.097688] do_check: env->insn_idx 16 [ 2.097774] do_check: env->insn_idx 17 [ 2.097866] do_check: env->insn_idx 18 [ 2.097990] do_check: env->insn_idx 19 [ 2.098050] do_check: env->insn_idx 20 [ 2.098119] do_check: env->insn_idx 21 [ 2.098195] do_check: env->insn_idx 20 [ 2.098347] do_check: env->insn_idx 21 [ 2.098414] do_check: env->insn_idx 14 [ 2.098556] do_check: env->insn_idx 15 [ 2.098629] do_check: env->insn_idx 16 [ 2.098700] do_check: env->insn_idx 17 [ 2.098767] do_check: env->insn_idx 18 [ 2.098842] do_check: env->insn_idx 8 [ 2.098984] do_check: env->insn_idx 9 [ 2.099108] do_check: env->insn_idx 8 [ 2.099171] do_check: env->insn_idx 9 [ 2.099304] do_check: env->insn_idx 8 [ 2.099368] do_check: env->insn_idx 9 [ 2.099505] do_check: env->insn_idx 8 [ 2.099568] do_check: env->insn_idx 9 [ 2.099703] do_check: env->insn_idx 8 [ 2.099774] do_check: env->insn_idx 9 [ 2.099921] do_check: env->insn_idx 8 [ 2.099984] do_check: env->insn_idx 9 [ 2.100133] do_check: env->insn_idx 8 [ 2.100200] do_check: env->insn_idx 9 [ 2.100349] do_check: env->insn_idx 8 [ 2.100413] do_check: env->insn_idx 9 [ 2.100503] do_check: env->insn_idx 10 [ 2.100566] do_check: env->insn_idx 11 [ 2.100636] do_check: env->insn_idx 12 [ 2.100813] do_check: env->insn_idx 13 [ 2.100909] do_check: env->insn_idx 14 [ 2.100972] do_check: env->insn_idx 15 [ 2.101047] do_check: env->insn_idx 16 [ 2.101117] do_check: env->insn_idx 17 [ 2.101185] do_check: env->insn_idx 18 [ 2.101250] do_check: env->insn_idx 14 [ 2.101389] do_check: env->insn_idx 15 [ 2.101462] do_check: env->insn_idx 16 [ 2.101531] do_check: env->insn_idx 17 [ 2.101598] do_check: env->insn_idx 18 ... verification repeats from LBL ... [...] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [bpf?] WARNING in push_jmp_history 2024-10-07 18:35 [syzbot] [bpf?] WARNING in push_jmp_history syzbot 2024-10-07 22:18 ` Eduard Zingerman @ 2024-10-08 8:43 ` syzbot 2024-10-08 9:41 ` Eduard Zingerman 1 sibling, 1 reply; 5+ messages in thread From: syzbot @ 2024-10-08 8:43 UTC (permalink / raw) To: 42.hyeyoo, akpm, andrii, ast, bpf, cl, daniel, eddyz87, feng.tang, haoluo, iamjoonsoo.kim, john.fastabend, jolsa, kpsingh, linux-kernel, linux-mm, martin.lau, penberg, rientjes, roman.gushchin, sdf, song, syzkaller-bugs, vbabka, yonghong.song syzbot has bisected this issue to: commit d0a38fad51cc70ab3dd3c59b54d8079ac19220b9 Author: Feng Tang <feng.tang@intel.com> Date: Wed Sep 11 06:45:34 2024 +0000 mm/slub: Improve redzone check and zeroing for krealloc() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11ddbb80580000 start commit: c02d24a5af66 Add linux-next specific files for 20241003 git tree: linux-next final oops: https://syzkaller.appspot.com/x/report.txt?x=13ddbb80580000 console output: https://syzkaller.appspot.com/x/log.txt?x=15ddbb80580000 kernel config: https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d dashboard link: https://syzkaller.appspot.com/bug?extid=7e46cdef14bf496a3ab4 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b82707980000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f4c327980000 Reported-by: syzbot+7e46cdef14bf496a3ab4@syzkaller.appspotmail.com Fixes: d0a38fad51cc ("mm/slub: Improve redzone check and zeroing for krealloc()") For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [bpf?] WARNING in push_jmp_history 2024-10-08 8:43 ` syzbot @ 2024-10-08 9:41 ` Eduard Zingerman 2024-10-08 10:01 ` Vlastimil Babka 0 siblings, 1 reply; 5+ messages in thread From: Eduard Zingerman @ 2024-10-08 9:41 UTC (permalink / raw) To: feng.tang Cc: syzbot, 42.hyeyoo, akpm, andrii, ast, bpf, cl, daniel, haoluo, iamjoonsoo.kim, john.fastabend, jolsa, kpsingh, linux-kernel, linux-mm, martin.lau, penberg, rientjes, roman.gushchin, sdf, song, syzkaller-bugs, vbabka, yonghong.song On Tue, 2024-10-08 at 01:43 -0700, syzbot wrote: > syzbot has bisected this issue to: > > commit d0a38fad51cc70ab3dd3c59b54d8079ac19220b9 > Author: Feng Tang <feng.tang@intel.com> > Date: Wed Sep 11 06:45:34 2024 +0000 > > mm/slub: Improve redzone check and zeroing for krealloc() > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11ddbb80580000 > start commit: c02d24a5af66 Add linux-next specific files for 20241003 > git tree: linux-next > final oops: https://syzkaller.appspot.com/x/report.txt?x=13ddbb80580000 > console output: https://syzkaller.appspot.com/x/log.txt?x=15ddbb80580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d > dashboard link: https://syzkaller.appspot.com/bug?extid=7e46cdef14bf496a3ab4 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b82707980000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f4c327980000 > > Reported-by: syzbot+7e46cdef14bf496a3ab4@syzkaller.appspotmail.com > Fixes: d0a38fad51cc ("mm/slub: Improve redzone check and zeroing for krealloc()") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection There are two issues demonstrated by this repro: - one is mm/slub related; - another one is verification taking forever. About the mm/slub related. Applying the following patch with additional logging on top of commit d0a38fad51cc identified by syzbot: ------- 8< ------------------------------------------------------------ diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 9a7ed527e47e..c1582a6d1d33 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3494,7 +3494,9 @@ static int push_jmp_history(struct bpf_verifier_env *env, struct bpf_verifier_st cnt++; alloc_size = kmalloc_size_roundup(size_mul(cnt, sizeof(*p))); + printk("push_jmp_history: #1 cur->jmp_history=%p\n", cur->jmp_history); p = krealloc(cur->jmp_history, alloc_size, GFP_USER); + printk("push_jmp_history: #2 cur->jmp_history=%p\n", p); if (!p) return -ENOMEM; cur->jmp_history = p; diff --git a/mm/slub.c b/mm/slub.c index e0fb0a26c796..3f5b080ac1f5 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4627,7 +4627,7 @@ static inline struct kmem_cache *virt_to_cache(const void *obj) struct slab *slab; slab = virt_to_slab(obj); - if (WARN_ONCE(!slab, "%s: Object is not a Slab page!\n", __func__)) + if (WARN_ONCE(!slab, "%s: Object %p is not a Slab page!\n", __func__, obj)) return NULL; return slab->slab_cache; } ------------------------------------------------------------ >8 ------- Produces the following log: l1: [ 2.942120] push_jmp_history: #2 cur->jmp_history=00000000a0f6f503 l2: [ 2.944445] push_jmp_history: #1 cur->jmp_history=00000000a0f6f503 l3: [ 2.944560] ------------[ cut here ]------------ l4: [ 2.944647] virt_to_cache: Object 00000000a0f6f503 is not a Slab page! l5: [ 2.944765] WARNING: CPU: 0 PID: 145 at mm/slub.c:4630 krealloc_noprof (mm/slub.c:4630 mm/slub.c:4728 mm/slub.c:4813) l6: [ 2.944906] Modules linked in: l7: [ 2.945134] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 l8: [ 2.945285] RIP: 0010:krealloc_noprof (mm/slub.c:4630 mm/slub.c:4728 mm/slub.c:4813) ... l9: [ 2.952088] BUG: kernel NULL pointer dereference, address: 000000000000001c l10: [ 2.952171] #PF: supervisor read access in kernel mode l11: [ 2.952240] #PF: error_code(0x0000) - not-present page l12: [ 2.952309] PGD 105d51067 P4D 105d51067 PUD 1013d0067 PMD 0 l13: [ 2.952402] Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI l14: [ 2.952611] Tainted: [W]=WARN l15: [ 2.952664] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 l16: [ 2.952794] RIP: 0010:krealloc_noprof (mm/slub.c:0 mm/slub.c:4729 mm/slub.c:4813) Lines l{1,2,4} show that address 0xa0f6f503 was first allocated by krealloc and then krealloc failed to recognize it as such. The warning at l3 is reported by virt_to_cache() called from __do_krealloc(): 4715 static __always_inline __realloc_size(2) void * 4716 __do_krealloc(const void *p, size_t new_size, gfp_t flags) 4717 { 4718 void *ret; 4719 size_t ks; 4720 int orig_size = 0; 4721 struct kmem_cache *s; 4722 4723 /* Check for double-free. */ 4724 if (likely(!ZERO_OR_NULL_PTR(p))) { 4725 if (!kasan_check_byte(p)) 4726 return NULL; 4727 4728 s = virt_to_cache(p); 4729 orig_size = get_orig_size(s, (void *)p); 4730 ks = s->object_size; When virt_to_cache() reports the warning it returns NULL. Hence variable 's' at line 4728 is NULL and this causes null pointer dereference at line 4730, reported at l9. Lines 4725-4730 were changed by commit d0a38fad51cc identified by syzbot, previously 'ks' was identified using other means. Feng, this issue seem unrelated to BPF verifier, could you please take a look? Best regards, Eduard ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [syzbot] [bpf?] WARNING in push_jmp_history 2024-10-08 9:41 ` Eduard Zingerman @ 2024-10-08 10:01 ` Vlastimil Babka 0 siblings, 0 replies; 5+ messages in thread From: Vlastimil Babka @ 2024-10-08 10:01 UTC (permalink / raw) To: Eduard Zingerman, feng.tang Cc: syzbot, 42.hyeyoo, akpm, andrii, ast, bpf, cl, daniel, haoluo, iamjoonsoo.kim, john.fastabend, jolsa, kpsingh, linux-kernel, linux-mm, martin.lau, penberg, rientjes, roman.gushchin, sdf, song, syzkaller-bugs, yonghong.song On 10/8/24 11:41, Eduard Zingerman wrote: > On Tue, 2024-10-08 at 01:43 -0700, syzbot wrote: >> syzbot has bisected this issue to: >> >> commit d0a38fad51cc70ab3dd3c59b54d8079ac19220b9 >> Author: Feng Tang <feng.tang@intel.com> >> Date: Wed Sep 11 06:45:34 2024 +0000 >> >> mm/slub: Improve redzone check and zeroing for krealloc() >> >> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11ddbb80580000 >> start commit: c02d24a5af66 Add linux-next specific files for 20241003 >> git tree: linux-next >> final oops: https://syzkaller.appspot.com/x/report.txt?x=13ddbb80580000 >> console output: https://syzkaller.appspot.com/x/log.txt?x=15ddbb80580000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d >> dashboard link: https://syzkaller.appspot.com/bug?extid=7e46cdef14bf496a3ab4 >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b82707980000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f4c327980000 >> >> Reported-by: syzbot+7e46cdef14bf496a3ab4@syzkaller.appspotmail.com >> Fixes: d0a38fad51cc ("mm/slub: Improve redzone check and zeroing for krealloc()") >> >> For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > There are two issues demonstrated by this repro: > - one is mm/slub related; > - another one is verification taking forever. > > About the mm/slub related. Applying the following patch with > additional logging on top of commit d0a38fad51cc identified by syzbot: The slab one is known from other reports and the problematic commit was removed from -next since then. > > ------- 8< ------------------------------------------------------------ > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 9a7ed527e47e..c1582a6d1d33 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -3494,7 +3494,9 @@ static int push_jmp_history(struct bpf_verifier_env *env, struct bpf_verifier_st > > cnt++; > alloc_size = kmalloc_size_roundup(size_mul(cnt, sizeof(*p))); > + printk("push_jmp_history: #1 cur->jmp_history=%p\n", cur->jmp_history); > p = krealloc(cur->jmp_history, alloc_size, GFP_USER); > + printk("push_jmp_history: #2 cur->jmp_history=%p\n", p); > if (!p) > return -ENOMEM; > cur->jmp_history = p; > diff --git a/mm/slub.c b/mm/slub.c > index e0fb0a26c796..3f5b080ac1f5 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -4627,7 +4627,7 @@ static inline struct kmem_cache *virt_to_cache(const void *obj) > struct slab *slab; > > slab = virt_to_slab(obj); > - if (WARN_ONCE(!slab, "%s: Object is not a Slab page!\n", __func__)) > + if (WARN_ONCE(!slab, "%s: Object %p is not a Slab page!\n", __func__, obj)) > return NULL; > return slab->slab_cache; > } > ------------------------------------------------------------ >8 ------- > > Produces the following log: > > l1: [ 2.942120] push_jmp_history: #2 cur->jmp_history=00000000a0f6f503 > l2: [ 2.944445] push_jmp_history: #1 cur->jmp_history=00000000a0f6f503 > l3: [ 2.944560] ------------[ cut here ]------------ > l4: [ 2.944647] virt_to_cache: Object 00000000a0f6f503 is not a Slab page! > l5: [ 2.944765] WARNING: CPU: 0 PID: 145 at mm/slub.c:4630 krealloc_noprof (mm/slub.c:4630 mm/slub.c:4728 mm/slub.c:4813) > l6: [ 2.944906] Modules linked in: > l7: [ 2.945134] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 > l8: [ 2.945285] RIP: 0010:krealloc_noprof (mm/slub.c:4630 mm/slub.c:4728 mm/slub.c:4813) > ... > l9: [ 2.952088] BUG: kernel NULL pointer dereference, address: 000000000000001c > l10: [ 2.952171] #PF: supervisor read access in kernel mode > l11: [ 2.952240] #PF: error_code(0x0000) - not-present page > l12: [ 2.952309] PGD 105d51067 P4D 105d51067 PUD 1013d0067 PMD 0 > l13: [ 2.952402] Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI > l14: [ 2.952611] Tainted: [W]=WARN > l15: [ 2.952664] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 > l16: [ 2.952794] RIP: 0010:krealloc_noprof (mm/slub.c:0 mm/slub.c:4729 mm/slub.c:4813) > > Lines l{1,2,4} show that address 0xa0f6f503 was first allocated by > krealloc and then krealloc failed to recognize it as such. > > The warning at l3 is reported by virt_to_cache() called from > __do_krealloc(): > > > 4715 static __always_inline __realloc_size(2) void * > 4716 __do_krealloc(const void *p, size_t new_size, gfp_t flags) > 4717 { > 4718 void *ret; > 4719 size_t ks; > 4720 int orig_size = 0; > 4721 struct kmem_cache *s; > 4722 > 4723 /* Check for double-free. */ > 4724 if (likely(!ZERO_OR_NULL_PTR(p))) { > 4725 if (!kasan_check_byte(p)) > 4726 return NULL; > 4727 > 4728 s = virt_to_cache(p); > 4729 orig_size = get_orig_size(s, (void *)p); > 4730 ks = s->object_size; > > When virt_to_cache() reports the warning it returns NULL. > Hence variable 's' at line 4728 is NULL and this causes null pointer > dereference at line 4730, reported at l9. > > Lines 4725-4730 were changed by commit d0a38fad51cc identified by syzbot, > previously 'ks' was identified using other means. > > Feng, this issue seem unrelated to BPF verifier, could you please take a look? > > Best regards, > Eduard > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-10-08 10:01 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-10-07 18:35 [syzbot] [bpf?] WARNING in push_jmp_history syzbot 2024-10-07 22:18 ` Eduard Zingerman 2024-10-08 8:43 ` syzbot 2024-10-08 9:41 ` Eduard Zingerman 2024-10-08 10:01 ` Vlastimil Babka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox