[syzbot] general protection fault in ax25_send_frame (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 0727a9a5fbc1 Documentation: mptcp: fix pm_type formatting
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=149755e8880000
kernel config: https://syzkaller.appspot.com/x/.config?x=58826a10ff282dbf
dashboard link: https://syzkaller.appspot.com/bug?extid=4643bc868f47ad276452
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/27e66e05ee01/disk-0727a9a5.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/df24b686590e/vmlinux-0727a9a5.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4643bc...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 0xdffffc000000006c: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367]
CPU: 1 PID: 10715 Comm: syz-executor.3 Not tainted 6.0.0-rc4-syzkaller-00136-g0727a9a5fbc1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
RIP: 0010:ax25_dev_ax25dev include/net/ax25.h:342 [inline]
RIP: 0010:ax25_send_frame+0xe4/0x640 net/ax25/ax25_out.c:56
Code: 00 48 85 c0 49 89 c4 0f 85 fb 03 00 00 e8 34 cb 2b f9 49 8d bd 60 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 b1 04 00 00 4d 8b ad 60 03 00 00 4d 85 ed 0f 84
RSP: 0000:ffffc90004c77a00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88814a308008 RCX: 0000000000000100
RDX: 000000000000006c RSI: ffffffff88503efc RDI: 0000000000000360
RBP: ffffffff91561460 R08: 0000000000000001 R09: ffffffff908e4a9f
R10: 0000000000000001 R11: 1ffffffff2020d9a R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000104 R15: 0000000000000000
FS: 0000555556215400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2f328000 CR3: 0000000050a64000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
rose_send_frame+0xcc/0x2f0 net/rose/rose_link.c:106
rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
__run_timers kernel/time/timer.c:1768 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
__do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
invoke_softirq kernel/softirq.c:445 [inline]
__irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+0x45/0xc0 arch/x86/kernel/apic/apic.c:1106
asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649
RIP: 0033:0x7fe1ccc37497
Code: 75 37 b8 00 00 00 80 48 01 d0 48 3d ff ff ff 7e 0f 87 2a 02 00 00 44 89 c0 c1 e8 10 44 31 c0 83 f0 3d 8d 04 c0 89 c7 c1 ef 04 <31> f8 69 c0 2d eb d4 27 31 c5 c1 e8 0f 31 c5 80 3d e4 de 09 01 00
RSP: 002b:00007fff5e3de460 EFLAGS: 00000a06
RAX: 000000009127bfa1 RBX: 00007fe1ccd9c018 RCX: 0000001b2f320000
RDX: ffffffff81e7790e RSI: 0000001b2f324438 RDI: 0000000009127bfa
RBP: 0000000081e7790e R08: ffffffff81e77903 R09: 00000000ab355ea3
R10: 00007fff5e3de630 R11: 0000000000000246 R12: 00007fe1ccd90000
R13: 0000000000000001 R14: 00000000000165f4 R15: ffffffff81e7790e
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ax25_dev_ax25dev include/net/ax25.h:342 [inline]
RIP: 0010:ax25_send_frame+0xe4/0x640 net/ax25/ax25_out.c:56
Code: 00 48 85 c0 49 89 c4 0f 85 fb 03 00 00 e8 34 cb 2b f9 49 8d bd 60 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 b1 04 00 00 4d 8b ad 60 03 00 00 4d 85 ed 0f 84
RSP: 0000:ffffc90004c77a00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88814a308008 RCX: 0000000000000100
RDX: 000000000000006c RSI: ffffffff88503efc RDI: 0000000000000360
RBP: ffffffff91561460 R08: 0000000000000001 R09: ffffffff908e4a9f
R10: 0000000000000001 R11: 1ffffffff2020d9a R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000104 R15: 0000000000000000
FS: 0000555556215400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2f328000 CR3: 0000000050a64000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 00 48 85 add %cl,-0x7b(%rax)
3: c0 49 89 c4 rorb $0xc4,-0x77(%rcx)
7: 0f 85 fb 03 00 00 jne 0x408
d: e8 34 cb 2b f9 callq 0xf92bcb46
12: 49 8d bd 60 03 00 00 lea 0x360(%r13),%rdi
19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
20: fc ff df
23: 48 89 fa mov %rdi,%rdx
26: 48 c1 ea 03 shr $0x3,%rdx
* 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction
2e: 0f 85 b1 04 00 00 jne 0x4e5
34: 4d 8b ad 60 03 00 00 mov 0x360(%r13),%r13
3b: 4d 85 ed test %r13,%r13
3e: 0f .byte 0xf
3f: 84 .byte 0x84


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[Peter Lafreniere]

In response to the following syzbot report:

> [...]
> </TASK>

The null dereference in ax25_dev_ax25dev() must be from a null struct
net_device* dev being passed to ax25_send_frame(). By tracing the call stack,
the null pointer can be shown as coming from the dev field of
rose_loopback_neigh being null.

The null dereference was already mitigated with a fail-silent check by
commit e97c089d7a49 ("rose: Fix NULL pointer dereference in rose_send_frame()")
in response to a previous syzbot report "general protection fault in
rose_send_frame (2)", which was not closed.

Does anyone object to marking syzbot bugs
"general protection fault in {ax25|rose}_send_frame (2)"
as fixed?

Respectfully,
Peter Lafreniere (N8PJL)

[Peter Lafreniere]

> Does anyone object to marking syzbot bugs
> "general protection fault in {ax25|rose}_send_frame (2)"
> as fixed?

As nobody seems to object to closing these reports:
#syz fix: rose: Fix NULL pointer dereference in rose_send_frame()

- Peter