Messages in this thread | | | From | Xin Long <> | Date | Thu, 23 Mar 2023 17:50:34 -0400 | Subject | Re: [syzbot] [sctp?] general protection fault in sctp_outq_tail |
| |
On Wed, Mar 22, 2023 at 8:39 PM syzbot <syzbot+47c24ca20a2fa01f082e@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com > > 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.
| |