On Wed, Mar 22, 2023 at 8:39 PM syzbot
[off-list ref] 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.