Re: general protection fault in sctp_sched_rr_dequeue

On Wed, Mar 06, 2019 at 07:03:10AM -0500, Neil Horman wrote:

On Wed, Mar 06, 2019 at 06:43:48PM +0800, Xin Long wrote:

quoted

On Wed, Mar 6, 2019 at 9:42 AM syzbot
[off-list ref] wrote:

quoted

Hello,

syzbot found the following crash on:

HEAD commit:    63bdf4284c38 Merge branch 'linus' of git://git.kernel.org/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=100347cb200000
kernel config:  https://syzkaller.appspot.com/x/.config?x=872be05707464aaa
dashboard link: https://syzkaller.appspot.com/bug?extid=4c9934f20522c0efd657
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11cd9b03200000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127de8e7200000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4c9934f20522c0efd657@syzkaller.appspotmail.com

kauditd_printk_skb: 2 callbacks suppressed
audit: type=1400 audit(1551833288.424:35): avc:  denied  { map } for
pid=8035 comm="bash" path="/bin/bash" dev="sda1" ino=1457
scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file permissive=1
audit: type=1400 audit(1551833294.934:36): avc:  denied  { map } for
pid=8047 comm="syz-executor778" path="/root/syz-executor778173561"
dev="sda1" ino=16484 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8047 Comm: syz-executor778 Not tainted 5.0.0+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:sctp_sched_rr_dequeue+0xd3/0x170 net/sctp/stream_sched_rr.c:141

The panic was caused by sched->init() reset stream->rr_next = NULL, even
if outq->out_chunk_list is not empty.

We should remove the sched->init() from sctp_stream_init(), since
all sched info was moved into sout->ext and sctp_stream_alloc_out()
will not afffect it.

I think what you're saying is we can just let sctp_outq_init handle the stream
scheduler initalization, correct?  If so, ACK to that approach
Neil

+1

  Marcelo