[syzbot] [bpf?] KMSAN: uninit-value in ieee802154_subif_start_xmit
7 messages,
3 authors,
2023-08-07 · open the first message on its own page
Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d61b595e9205573133b3@syzkaller.appspotmail.com
Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns")
general protection fault, probably for non-canonical address 0xdffffc0000000f4f: 0000 [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range [0x0000000000007a78-0x0000000000007a7f]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.5.0-rc2-syzkaller-00619-g25ad10658dc1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bpf_bprintf_prepare+0x127/0x1490 kernel/bpf/helpers.c:823
____bpf_trace_printk kernel/trace/bpf_trace.c:385 [inline]
bpf_trace_printk+0xdb/0x180 kernel/trace/bpf_trace.c:375
bpf_prog_ebeed182d92b487f+0x38/0x3c
bpf_dispatcher_nop_func include/linux/bpf.h:1180 [inline]
__bpf_prog_run include/linux/filter.h:609 [inline]
bpf_prog_run include/linux/filter.h:616 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2269 [inline]
bpf_trace_run1+0x148/0x400 kernel/trace/bpf_trace.c:2307
__bpf_trace_rcu_utilization+0x8e/0xc0 include/trace/events/rcu.h:27
trace_rcu_utilization+0xcd/0x120 include/trace/events/rcu.h:27
rcu_note_context_switch+0x6c/0x1ac0 kernel/rcu/tree_plugin.h:318
__schedule+0x293/0x59f0 kernel/sched/core.c:6610
schedule_idle+0x5b/0x80 kernel/sched/core.c:6814
do_idle+0x288/0x3f0 kernel/sched/idle.c:310
cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:379
start_secondary+0x200/0x290 arch/x86/kernel/smpboot.c:326
secondary_startup_64_no_verify+0x167/0x16b
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 90 nop
5: f3 0f 1e fa endbr64
9: 53 push %rbx
a: 48 01 fe add %rdi,%rsi
d: 48 bb 00 00 00 00 00 movabs $0xdffffc0000000000,%rbx
14: fc ff df
17: 48 83 ec 18 sub $0x18,%rsp
1b: eb 28 jmp 0x45
1d: 48 89 f8 mov %rdi,%rax
20: 48 89 f9 mov %rdi,%rcx
23: 48 c1 e8 03 shr $0x3,%rax
27: 83 e1 07 and $0x7,%ecx
* 2a: 0f b6 04 18 movzbl (%rax,%rbx,1),%eax <-- trapping instruction
2e: 38 c8 cmp %cl,%al
30: 7f 04 jg 0x36
32: 84 c0 test %al,%al
34: 75 25 jne 0x5b
36: 0f b6 07 movzbl (%rdi),%eax
39: 38 d0 cmp %dl,%al
3b: 74 15 je 0x52
3d: 48 rex.W
3e: 83 .byte 0x83
3f: c7 .byte 0xc7
---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
If the bug is already fixed, 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 change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
On 8/6/23 4:23 PM, syzbot wrote: Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
Thanks for reporting. I will look into this ASAP.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d61b595e9205573133b3@syzkaller.appspotmail.com
Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns")
general protection fault, probably for non-canonical address 0xdffffc0000000f4f: 0000 [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range [0x0000000000007a78-0x0000000000007a7f]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.5.0-rc2-syzkaller-00619-g25ad10658dc1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bpf_bprintf_prepare+0x127/0x1490 kernel/bpf/helpers.c:823
____bpf_trace_printk kernel/trace/bpf_trace.c:385 [inline]
bpf_trace_printk+0xdb/0x180 kernel/trace/bpf_trace.c:375
bpf_prog_ebeed182d92b487f+0x38/0x3c
bpf_dispatcher_nop_func include/linux/bpf.h:1180 [inline]
__bpf_prog_run include/linux/filter.h:609 [inline]
bpf_prog_run include/linux/filter.h:616 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2269 [inline]
bpf_trace_run1+0x148/0x400 kernel/trace/bpf_trace.c:2307
__bpf_trace_rcu_utilization+0x8e/0xc0 include/trace/events/rcu.h:27
trace_rcu_utilization+0xcd/0x120 include/trace/events/rcu.h:27
rcu_note_context_switch+0x6c/0x1ac0 kernel/rcu/tree_plugin.h:318
__schedule+0x293/0x59f0 kernel/sched/core.c:6610
schedule_idle+0x5b/0x80 kernel/sched/core.c:6814
do_idle+0x288/0x3f0 kernel/sched/idle.c:310
cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:379
start_secondary+0x200/0x290 arch/x86/kernel/smpboot.c:326
secondary_startup_64_no_verify+0x167/0x16b
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 90 nop
5: f3 0f 1e fa endbr64
9: 53 push %rbx
a: 48 01 fe add %rdi,%rsi
d: 48 bb 00 00 00 00 00 movabs $0xdffffc0000000000,%rbx
14: fc ff df
17: 48 83 ec 18 sub $0x18,%rsp
1b: eb 28 jmp 0x45
1d: 48 89 f8 mov %rdi,%rax
20: 48 89 f9 mov %rdi,%rcx
23: 48 c1 e8 03 shr $0x3,%rax
27: 83 e1 07 and $0x7,%ecx
* 2a: 0f b6 04 18 movzbl (%rax,%rbx,1),%eax <-- trapping instruction
2e: 38 c8 cmp %cl,%al
30: 7f 04 jg 0x36
32: 84 c0 test %al,%al
34: 75 25 jne 0x5b
36: 0f b6 07 movzbl (%rdi),%eax
39: 38 d0 cmp %dl,%al
3b: 74 15 je 0x52
3d: 48 rex.W
3e: 83 .byte 0x83
3f: c7 .byte 0xc7
[...]
On Sun, 2023-08-06 at 23:40 -0700, Yonghong Song wrote:
On 8/6/23 4:23 PM, syzbot wrote: quoted Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
Thanks for reporting. I will look into this ASAP.
Hi Yonghong,
I guess it's your night and my morning, so I did some initial assessment.
The BPF program being loaded is:
0 : (62) *(u32 *)(r10 -8) = 553656332
1 : (bf) r1 = (s16)r10
2 : (07) r1 += -8
3 : (b7) r2 = 3
4 : (bd) if r2 <= r1 goto pc+0
5 : (85) call bpf_trace_printk#6
6 : (b7) r0 = 0
7 : (95) exit
(Note: when using bpftool (prog dump xlated id <some-id>) the disassembly
of the instruction #1 is incorrectly printed as "1: (bf) r1 = r10")
The error occurs when instruction #5 (call to printk) is executed.
An incorrect address for the format string is passed to printk.
Disassembly of the jited program looks as follows:
$ bpftool prog dump jited id <some-id>
bpf_prog_ebeed182d92b487f:
0: nopl (%rax,%rax)
5: nop
7: pushq %rbp
8: movq %rsp, %rbp
b: subq $8, %rsp
12: movl $553656332, -8(%rbp)
19: movswq %bp, %rdi ; <---- Note movswq %bp !
1d: addq $-8, %rdi
21: movl $3, %esi
26: cmpq %rdi, %rsi
29: jbe 0x2b
2b: callq 0xffffffffe11c484c
30: xorl %eax, %eax
32: leave
33: retq
Note jit instruction #19 corresponding to BPF instruction #1, which
loads truncated and sign-extended value of %rbp's first byte as an
address of format string.
Here is how verifier log looks for (slightly modified) program:
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
; asm volatile (" \n\
0: (b7) r1 = 553656332 ; R1_w=553656332
1: (63) *(u32 *)(r10 -8) = r1 ; R1_w=553656332 R10=fp0 fp-8=553656332
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
3: (07) r1 += -8 ; R1_w=fp-8
4: (b7) r2 = 3 ; R2_w=3
5: (bd) if r2 <= r1 goto pc+0 ; R1_w=fp-8 R2_w=3
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: R0=scalar()
7: (b7) r0 = 0 ; R0_w=0
8: (95) exit
from 5 to 6: R1_w=fp-8 R2_w=3 R10=fp0 fp-8=553656332
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: safe
Note the following line:
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
Verifier incorrectly marked r1 as fp0, hence not noticing the problem
with address passed to printk.
Thanks,
Eduard.
quoted
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d61b595e9205573133b3@syzkaller.appspotmail.com
Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns")
general protection fault, probably for non-canonical address 0xdffffc0000000f4f: 0000 [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range [0x0000000000007a78-0x0000000000007a7f]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.5.0-rc2-syzkaller-00619-g25ad10658dc1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bpf_bprintf_prepare+0x127/0x1490 kernel/bpf/helpers.c:823
____bpf_trace_printk kernel/trace/bpf_trace.c:385 [inline]
bpf_trace_printk+0xdb/0x180 kernel/trace/bpf_trace.c:375
bpf_prog_ebeed182d92b487f+0x38/0x3c
bpf_dispatcher_nop_func include/linux/bpf.h:1180 [inline]
__bpf_prog_run include/linux/filter.h:609 [inline]
bpf_prog_run include/linux/filter.h:616 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2269 [inline]
bpf_trace_run1+0x148/0x400 kernel/trace/bpf_trace.c:2307
__bpf_trace_rcu_utilization+0x8e/0xc0 include/trace/events/rcu.h:27
trace_rcu_utilization+0xcd/0x120 include/trace/events/rcu.h:27
rcu_note_context_switch+0x6c/0x1ac0 kernel/rcu/tree_plugin.h:318
__schedule+0x293/0x59f0 kernel/sched/core.c:6610
schedule_idle+0x5b/0x80 kernel/sched/core.c:6814
do_idle+0x288/0x3f0 kernel/sched/idle.c:310
cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:379
start_secondary+0x200/0x290 arch/x86/kernel/smpboot.c:326
secondary_startup_64_no_verify+0x167/0x16b
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:strnchr+0x25/0x80 lib/string.c:403
Code: 00 00 00 00 90 f3 0f 1e fa 53 48 01 fe 48 bb 00 00 00 00 00 fc ff df 48 83 ec 18 eb 28 48 89 f8 48 89 f9 48 c1 e8 03 83 e1 07 <0f> b6 04 18 38 c8 7f 04 84 c0 75 25 0f b6 07 38 d0 74 15 48 83 c7
RSP: 0018:ffffc90000177848 EFLAGS: 00010046
RAX: 0000000000000f4f RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000007a7b RDI: 0000000000007a78
RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000007a78
R13: ffffc900001779b0 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005611db5094b8 CR3: 0000000028ef0000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 90 nop
5: f3 0f 1e fa endbr64
9: 53 push %rbx
a: 48 01 fe add %rdi,%rsi
d: 48 bb 00 00 00 00 00 movabs $0xdffffc0000000000,%rbx
14: fc ff df
17: 48 83 ec 18 sub $0x18,%rsp
1b: eb 28 jmp 0x45
1d: 48 89 f8 mov %rdi,%rax
20: 48 89 f9 mov %rdi,%rcx
23: 48 c1 e8 03 shr $0x3,%rax
27: 83 e1 07 and $0x7,%ecx
* 2a: 0f b6 04 18 movzbl (%rax,%rbx,1),%eax <-- trapping instruction
2e: 38 c8 cmp %cl,%al
30: 7f 04 jg 0x36
32: 84 c0 test %al,%al
34: 75 25 jne 0x5b
36: 0f b6 07 movzbl (%rdi),%eax
39: 38 d0 cmp %dl,%al
3b: 74 15 je 0x52
3d: 48 rex.W
3e: 83 .byte 0x83
3f: c7 .byte 0xc7
[...]
On Mon, 2023-08-07 at 16:11 +0300, Eduard Zingerman wrote:
[...] $ bpftool prog dump jited id <some-id>
bpf_prog_ebeed182d92b487f:
0: nopl (%rax,%rax)
5: nop
7: pushq %rbp
8: movq %rsp, %rbp
b: subq $8, %rsp
12: movl $553656332, -8(%rbp)
19: movswq %bp, %rdi ; <---- Note movswq %bp !
1d: addq $-8, %rdi
21: movl $3, %esi
26: cmpq %rdi, %rsi
29: jbe 0x2b
2b: callq 0xffffffffe11c484c
30: xorl %eax, %eax
32: leave
33: retq
Note jit instruction #19 corresponding to BPF instruction #1, which
loads truncated and sign-extended value of %rbp's first byte as an
address of format string.
Correction: sign-extended value of %rbp's first *two* bytes,
disassembly with opcodes:
19: movswq %bp, %rdi
48 0f bf fd
[...]
On 8/7/23 6:11 AM, Eduard Zingerman wrote: On Sun, 2023-08-06 at 23:40 -0700, Yonghong Song wrote: quoted
On 8/6/23 4:23 PM, syzbot wrote: quoted Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
Thanks for reporting. I will look into this ASAP.
Hi Yonghong,
I guess it's your night and my morning, so I did some initial assessment.
The BPF program being loaded is:
0 : (62) *(u32 *)(r10 -8) = 553656332
1 : (bf) r1 = (s16)r10
2 : (07) r1 += -8
3 : (b7) r2 = 3
4 : (bd) if r2 <= r1 goto pc+0
5 : (85) call bpf_trace_printk#6
6 : (b7) r0 = 0
7 : (95) exit
(Note: when using bpftool (prog dump xlated id <some-id>) the disassembly
of the instruction #1 is incorrectly printed as "1: (bf) r1 = r10")
The error occurs when instruction #5 (call to printk) is executed.
An incorrect address for the format string is passed to printk.
Disassembly of the jited program looks as follows:
$ bpftool prog dump jited id <some-id>
bpf_prog_ebeed182d92b487f:
0: nopl (%rax,%rax)
5: nop
7: pushq %rbp
8: movq %rsp, %rbp
b: subq $8, %rsp
12: movl $553656332, -8(%rbp)
19: movswq %bp, %rdi ; <---- Note movswq %bp !
1d: addq $-8, %rdi
21: movl $3, %esi
26: cmpq %rdi, %rsi
29: jbe 0x2b
2b: callq 0xffffffffe11c484c
30: xorl %eax, %eax
32: leave
33: retq
Note jit instruction #19 corresponding to BPF instruction #1, which
loads truncated and sign-extended value of %rbp's first byte as an
address of format string.
Here is how verifier log looks for (slightly modified) program:
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
; asm volatile (" \n\
0: (b7) r1 = 553656332 ; R1_w=553656332
1: (63) *(u32 *)(r10 -8) = r1 ; R1_w=553656332 R10=fp0 fp-8=553656332
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
3: (07) r1 += -8 ; R1_w=fp-8
4: (b7) r2 = 3 ; R2_w=3
5: (bd) if r2 <= r1 goto pc+0 ; R1_w=fp-8 R2_w=3
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: R0=scalar()
7: (b7) r0 = 0 ; R0_w=0
8: (95) exit
from 5 to 6: R1_w=fp-8 R2_w=3 R10=fp0 fp-8=553656332
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: safe
Note the following line:
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
Verifier incorrectly marked r1 as fp0, hence not noticing the problem
with address passed to printk.
Thanks, Eduard. Right. I am also able to dump xlated code like
below:
0: (62) *(u32 *)(r10 -8) = 553656332
1: (bf) r1 = (s16)r10
2: (07) r1 += -8
3: (b7) r2 = 3
4: (bd) if r2 <= r1 goto pc+0
5: (85) call bpf_trace_printk#-138320
6: (b7) r0 = 0
7: (95) exit
Something like below can fix the problem,
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 132f25dab931..db72619551b2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c @@ -13171,6 +13171,7 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
if (no_sext && need_id)
src_reg->id =
++env->id_gen;
copy_register_state(dst_reg,
src_reg);
+ dst_reg->type = SCALAR_VALUE;
if (!no_sext)
dst_reg->id = 0;
coerce_reg_to_size_sx(dst_reg,
insn->off >> 3);
After insn 1, we need change r1 type to SCALAR_VALUE. Will add
the the test to selftest and submit the patch to fix the problem
today.
Thanks,
Eduard.
quoted quoted
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000 [...]
On Mon, 2023-08-07 at 07:40 -0700, Yonghong Song wrote: quoted hunk
On 8/7/23 6:11 AM, Eduard Zingerman wrote: quoted On Sun, 2023-08-06 at 23:40 -0700, Yonghong Song wrote: quoted
On 8/6/23 4:23 PM, syzbot wrote: quoted Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
Thanks for reporting. I will look into this ASAP.
Hi Yonghong,
I guess it's your night and my morning, so I did some initial assessment.
The BPF program being loaded is:
0 : (62) *(u32 *)(r10 -8) = 553656332
1 : (bf) r1 = (s16)r10
2 : (07) r1 += -8
3 : (b7) r2 = 3
4 : (bd) if r2 <= r1 goto pc+0
5 : (85) call bpf_trace_printk#6
6 : (b7) r0 = 0
7 : (95) exit
(Note: when using bpftool (prog dump xlated id <some-id>) the disassembly
of the instruction #1 is incorrectly printed as "1: (bf) r1 = r10")
The error occurs when instruction #5 (call to printk) is executed.
An incorrect address for the format string is passed to printk.
Disassembly of the jited program looks as follows:
$ bpftool prog dump jited id <some-id>
bpf_prog_ebeed182d92b487f:
0: nopl (%rax,%rax)
5: nop
7: pushq %rbp
8: movq %rsp, %rbp
b: subq $8, %rsp
12: movl $553656332, -8(%rbp)
19: movswq %bp, %rdi ; <---- Note movswq %bp !
1d: addq $-8, %rdi
21: movl $3, %esi
26: cmpq %rdi, %rsi
29: jbe 0x2b
2b: callq 0xffffffffe11c484c
30: xorl %eax, %eax
32: leave
33: retq
Note jit instruction #19 corresponding to BPF instruction #1, which
loads truncated and sign-extended value of %rbp's first byte as an
address of format string.
Here is how verifier log looks for (slightly modified) program:
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
; asm volatile (" \n\
0: (b7) r1 = 553656332 ; R1_w=553656332
1: (63) *(u32 *)(r10 -8) = r1 ; R1_w=553656332 R10=fp0 fp-8=553656332
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
3: (07) r1 += -8 ; R1_w=fp-8
4: (b7) r2 = 3 ; R2_w=3
5: (bd) if r2 <= r1 goto pc+0 ; R1_w=fp-8 R2_w=3
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: R0=scalar()
7: (b7) r0 = 0 ; R0_w=0
8: (95) exit
from 5 to 6: R1_w=fp-8 R2_w=3 R10=fp0 fp-8=553656332
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: safe
Note the following line:
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
Verifier incorrectly marked r1 as fp0, hence not noticing the problem
with address passed to printk.
Thanks, Eduard. Right. I am also able to dump xlated code like
below:
0: (62) *(u32 *)(r10 -8) = 553656332
1: (bf) r1 = (s16)r10
2: (07) r1 += -8
3: (b7) r2 = 3
4: (bd) if r2 <= r1 goto pc+0
5: (85) call bpf_trace_printk#-138320
6: (b7) r0 = 0
7: (95) exit
Something like below can fix the problem,
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 132f25dab931..db72619551b2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c @@ -13171,6 +13171,7 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
if (no_sext && need_id)
src_reg->id =
++env->id_gen;
copy_register_state(dst_reg,
src_reg);
+ dst_reg->type = SCALAR_VALUE;
if (!no_sext)
dst_reg->id = 0;
coerce_reg_to_size_sx(dst_reg,
insn->off >> 3);
After insn 1, we need change r1 type to SCALAR_VALUE. Will add
the the test to selftest and submit the patch to fix the problem
today.
Should this be an error?
Like in the same function but slightly below, when u32 moves are
processed:
/* R1 = (u32) R2 */
if (is_pointer_value(env, insn->src_reg)) {
verbose(env,
"R%d partial copy of pointer\n",
insn->src_reg);
return -EACCES;
} else { ...
quoted
Thanks,
Eduard.
quoted quoted
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000 [...]
On 8/7/23 7:45 AM, Eduard Zingerman wrote: On Mon, 2023-08-07 at 07:40 -0700, Yonghong Song wrote: quoted
On 8/7/23 6:11 AM, Eduard Zingerman wrote: quoted On Sun, 2023-08-06 at 23:40 -0700, Yonghong Song wrote: quoted
On 8/6/23 4:23 PM, syzbot wrote: quoted Hello,
syzbot found the following issue on:
HEAD commit: 25ad10658dc1 riscv, bpf: Adapt bpf trampoline to optimized..
git tree: bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147cbb29a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=8acaeb93ad7c6aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=d61b595e9205573133b3
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d73ccea80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276aedea80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d378cc13d42/disk-25ad1065.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/44580fd5d1af/vmlinux-25ad1065.xz
kernel image: https://storage.googleapis.com/syzbot-assets/840587618b41/bzImage-25ad1065.xz
The issue was bisected to:
commit 8100928c881482a73ed8bd499d602bab0fe55608
Author: Yonghong Song [off-list ref]
Date: Fri Jul 28 01:12:02 2023 +0000
bpf: Support new sign-extension mov insns
Thanks for reporting. I will look into this ASAP.
Hi Yonghong,
I guess it's your night and my morning, so I did some initial assessment.
The BPF program being loaded is:
0 : (62) *(u32 *)(r10 -8) = 553656332
1 : (bf) r1 = (s16)r10
2 : (07) r1 += -8
3 : (b7) r2 = 3
4 : (bd) if r2 <= r1 goto pc+0
5 : (85) call bpf_trace_printk#6
6 : (b7) r0 = 0
7 : (95) exit
(Note: when using bpftool (prog dump xlated id <some-id>) the disassembly
of the instruction #1 is incorrectly printed as "1: (bf) r1 = r10")
The error occurs when instruction #5 (call to printk) is executed.
An incorrect address for the format string is passed to printk.
Disassembly of the jited program looks as follows:
$ bpftool prog dump jited id <some-id>
bpf_prog_ebeed182d92b487f:
0: nopl (%rax,%rax)
5: nop
7: pushq %rbp
8: movq %rsp, %rbp
b: subq $8, %rsp
12: movl $553656332, -8(%rbp)
19: movswq %bp, %rdi ; <---- Note movswq %bp !
1d: addq $-8, %rdi
21: movl $3, %esi
26: cmpq %rdi, %rsi
29: jbe 0x2b
2b: callq 0xffffffffe11c484c
30: xorl %eax, %eax
32: leave
33: retq
Note jit instruction #19 corresponding to BPF instruction #1, which
loads truncated and sign-extended value of %rbp's first byte as an
address of format string.
Here is how verifier log looks for (slightly modified) program:
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
; asm volatile (" \n\
0: (b7) r1 = 553656332 ; R1_w=553656332
1: (63) *(u32 *)(r10 -8) = r1 ; R1_w=553656332 R10=fp0 fp-8=553656332
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
3: (07) r1 += -8 ; R1_w=fp-8
4: (b7) r2 = 3 ; R2_w=3
5: (bd) if r2 <= r1 goto pc+0 ; R1_w=fp-8 R2_w=3
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: R0=scalar()
7: (b7) r0 = 0 ; R0_w=0
8: (95) exit
from 5 to 6: R1_w=fp-8 R2_w=3 R10=fp0 fp-8=553656332
6: (85) call bpf_trace_printk#6
mark_precise: frame0: last_idx 6 first_idx 0 subseq_idx -1
...
mark_precise: frame0: falling back to forcing all scalars precise
7: safe
Note the following line:
2: (bf) r1 = (s16)r10 ; R1_w=fp0 R10=fp0
Verifier incorrectly marked r1 as fp0, hence not noticing the problem
with address passed to printk.
Thanks, Eduard. Right. I am also able to dump xlated code like
below:
0: (62) *(u32 *)(r10 -8) = 553656332
1: (bf) r1 = (s16)r10
2: (07) r1 += -8
3: (b7) r2 = 3
4: (bd) if r2 <= r1 goto pc+0
5: (85) call bpf_trace_printk#-138320
6: (b7) r0 = 0
7: (95) exit
Something like below can fix the problem,
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 132f25dab931..db72619551b2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c @@ -13171,6 +13171,7 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
if (no_sext && need_id)
src_reg->id =
++env->id_gen;
copy_register_state(dst_reg,
src_reg);
+ dst_reg->type = SCALAR_VALUE;
if (!no_sext)
dst_reg->id = 0;
coerce_reg_to_size_sx(dst_reg,
insn->off >> 3);
After insn 1, we need change r1 type to SCALAR_VALUE. Will add
the the test to selftest and submit the patch to fix the problem
today.
Should this be an error?
Like in the same function but slightly below, when u32 moves are
processed:
/* R1 = (u32) R2 */
if (is_pointer_value(env, insn->src_reg)) {
verbose(env,
"R%d partial copy of pointer\n",
insn->src_reg);
return -EACCES;
} else { ...
Right, this is indeed better for unprivileged prog run.
I have submitted a patch to fix the issue reported by syzbot.
Please help review. Thanks!
quoted quoted
Thanks,
Eduard.
quoted quoted
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17970c5da80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14570c5da80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10570c5da80000 [...]