Re: [syzbot] [sctp?] general protection fault in sctp_outq_tail

[Xin Long]

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.