On Wed, Mar 22, 2023 at 8:39 PM syzbot <syzbot+47c24ca20a2fa01f082e@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: cdd28833100c net: microchip: sparx5: fix deletion of exist.. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=1588fe92c80000 > kernel config: https://syzkaller.appspot.com/x/.config?x=cab35c936731a347 > dashboard link: https://syzkaller.appspot.com/bug?extid=47c24ca20a2fa01f082e > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d80ff4c80000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f6e90ac80000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/2fb6257d1131/disk-cdd28833.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/a3025d79117c/vmlinux-cdd28833.xz > kernel image: https://storage.googleapis.com/syzbot-assets/8e6d670a5fed/bzImage-cdd28833.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+47c24ca20a2fa01f082e@xxxxxxxxxxxxxxxxxxxxxxxxx > > general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] PREEMPT SMP KASAN > KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] > CPU: 1 PID: 5783 Comm: syz-executor825 Not tainted 6.2.0-syzkaller-12889-gcdd28833100c #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > RIP: 0010:list_add_tail include/linux/list.h:102 [inline] > RIP: 0010:sctp_outq_tail_data net/sctp/outqueue.c:91 [inline] The null-ptr-deref is 'SCTP_SO(&q->asoc->stream, stream)->ext' in sctp_outq_tail_data(). It should be set in sctp_sendmsg_to_asoc(), unless the out stream got shrunk by: sctp_stream_update() -> sctp_stream_outq_migrate() -> sctp_stream_shrink_out(). When sending msgs on a closed association, it will first do handshakes. During the handshake, send more data with a big stream_num N until the tx buffer is full and the sending is waiting for more buffer, then after the handshakes are over and the big stream N is freed during the handshakes(which may happen when peer doesn't support so many streams), and the sending waiting for the tx buffer will try to enqueue data on a freed out stream, then this issue occurred. I will confirm this and give a fix. Thanks.
