Re: general protection fault in sctp_sched_rr_dequeue

[Marcelo Ricardo Leitner]

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:
> > On Wed, Mar 6, 2019 at 9:42 AM syzbot
> > <syzbot+4c9934f20522c0efd657@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > 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