* Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free
[not found] ` <20171221131333.GO6122@localhost.localdomain>
@ 2017-12-22 5:31 ` Xin Long
2018-01-30 23:03 ` Eric Biggers
0 siblings, 1 reply; 3+ messages in thread
From: Xin Long @ 2017-12-22 5:31 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
>
> from the log:
> [ 89.451366] FAULT_INJECTION: forcing a failure.^M
> [ 89.451366] name failslab, interval 1, probability 0, space 0,
> times 0^M
> [ 89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> +4.15.0-rc3-next-20171214+ #67^M
> [ 89.451377] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS
> +Google 01/01/2011^M
> [ 89.451380] Call Trace:^M
> [ 89.451395] dump_stack+0xe9/0x14b^M
> [ 89.451408] should_fail+0x1e5/0x220^M
> [ 89.451419] should_failslab+0x73/0x90^M
> [ 89.451428] __kmalloc+0x63/0x730^M
> [ 89.451439] ? rcu_read_lock_sched_held+0x74/0x80^M
> [ 89.451446] ? __kmalloc+0x4ac/0x730^M
> [ 89.451452] ? sctp_stream_alloc_in+0x2f/0x100^M
> [ 89.451464] sctp_stream_alloc_in+0x2f/0x100^M
> [ 89.451473] sctp_stream_init+0xfa/0x140^M
> [ 89.451485] sctp_process_init+0x676/0xc50^M
>
> this is what caused the panic later, because in the error path we free
> out but don't zero outcnt. This patch should fix it. Can you please
> try it? Thanks
>
> ----8<---
>
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 06b644dd858c..50ab09029f00 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
> sched->free(stream);
> kfree(stream->out);
> stream->out = NULL;
> + stream->outcnt = 0;
> out:
> return ret;
> }
In case it can't be verified due to no reproducer yet, I modified some
code in sctp_stream_init() to confirm Marcelo's deduction:
- i = sctp_stream_alloc_in(stream, incnt, gfp);
+ i = 1;
if (i) {
ret = -ENOMEM;
goto free;
And got the same call trace as the mail:
[ 301.488065] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[ 301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
[ 301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
[ 301.489372] Oops: 0000 [#1] SMP
[...]
[ 301.497647] Call Trace:
[ 301.497812] <IRQ>
[ 301.497955] sctp_association_free+0xb8/0x210 [sctp]
[ 301.498306] sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
[ 301.498654] sctp_do_sm+0x9a/0x2d0 [sctp]
[ 301.498921] ? sctp_has_association+0x130/0x130 [sctp]
[ 301.499301] ? kernel_text_address+0xba/0xe0
[ 301.499615] ? check_usage_backwards+0x88/0x150
[ 301.499911] ? __lock_acquire+0x280/0x1080
[ 301.500200] ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
[ 301.500593] sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
[ 301.500923] sctp_rcv+0x9f5/0xbe0 [sctp]
And Marcelo's patch could fix it.
Since the "free:" part only works for if (i), maybe the patch can also do:
if (i) {
sched->free(stream);
kfree(stream->out);
stream->out = NULL;
stream->outcnt = 0;
ret = -ENOMEM;
goto out;
}
and remove the "free:" path.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free
2017-12-22 5:31 ` BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free Xin Long
@ 2018-01-30 23:03 ` Eric Biggers
2018-01-31 7:23 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 3+ messages in thread
From: Eric Biggers @ 2018-01-30 23:03 UTC (permalink / raw)
To: Xin Long
Cc: Marcelo Ricardo Leitner, syzbot, davem, LKML, linux-sctp,
network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich
On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote:
> On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
> >
> > from the log:
> > [ 89.451366] FAULT_INJECTION: forcing a failure.^M
> > [ 89.451366] name failslab, interval 1, probability 0, space 0,
> > times 0^M
> > [ 89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> > +4.15.0-rc3-next-20171214+ #67^M
> > [ 89.451377] Hardware name: Google Google Compute Engine/Google
> > Compute Engine, BIOS
> > +Google 01/01/2011^M
> > [ 89.451380] Call Trace:^M
> > [ 89.451395] dump_stack+0xe9/0x14b^M
> > [ 89.451408] should_fail+0x1e5/0x220^M
> > [ 89.451419] should_failslab+0x73/0x90^M
> > [ 89.451428] __kmalloc+0x63/0x730^M
> > [ 89.451439] ? rcu_read_lock_sched_held+0x74/0x80^M
> > [ 89.451446] ? __kmalloc+0x4ac/0x730^M
> > [ 89.451452] ? sctp_stream_alloc_in+0x2f/0x100^M
> > [ 89.451464] sctp_stream_alloc_in+0x2f/0x100^M
> > [ 89.451473] sctp_stream_init+0xfa/0x140^M
> > [ 89.451485] sctp_process_init+0x676/0xc50^M
> >
> > this is what caused the panic later, because in the error path we free
> > out but don't zero outcnt. This patch should fix it. Can you please
> > try it? Thanks
> >
> > ----8<---
> >
> > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > index 06b644dd858c..50ab09029f00 100644
> > --- a/net/sctp/stream.c
> > +++ b/net/sctp/stream.c
> > @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
> > sched->free(stream);
> > kfree(stream->out);
> > stream->out = NULL;
> > + stream->outcnt = 0;
> > out:
> > return ret;
> > }
>
> In case it can't be verified due to no reproducer yet, I modified some
> code in sctp_stream_init() to confirm Marcelo's deduction:
> - i = sctp_stream_alloc_in(stream, incnt, gfp);
> + i = 1;
> if (i) {
> ret = -ENOMEM;
> goto free;
>
> And got the same call trace as the mail:
>
> [ 301.488065] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000008
> [ 301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
> [ 301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
> [ 301.489372] Oops: 0000 [#1] SMP
> [...]
> [ 301.497647] Call Trace:
> [ 301.497812] <IRQ>
> [ 301.497955] sctp_association_free+0xb8/0x210 [sctp]
> [ 301.498306] sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
> [ 301.498654] sctp_do_sm+0x9a/0x2d0 [sctp]
> [ 301.498921] ? sctp_has_association+0x130/0x130 [sctp]
> [ 301.499301] ? kernel_text_address+0xba/0xe0
> [ 301.499615] ? check_usage_backwards+0x88/0x150
> [ 301.499911] ? __lock_acquire+0x280/0x1080
> [ 301.500200] ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
> [ 301.500593] sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
> [ 301.500923] sctp_rcv+0x9f5/0xbe0 [sctp]
>
> And Marcelo's patch could fix it.
>
> Since the "free:" part only works for if (i), maybe the patch can also do:
> if (i) {
> sched->free(stream);
> kfree(stream->out);
> stream->out = NULL;
> stream->outcnt = 0;
>
> ret = -ENOMEM;
> goto out;
> }
>
> and remove the "free:" path.
This crash seems to have stopped occurring now. I presume it was fixed by the
following commit, so let's tell syzbot to close the bug:
#syz fix: sctp: fix error path in sctp_stream_init
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free
2018-01-30 23:03 ` Eric Biggers
@ 2018-01-31 7:23 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 3+ messages in thread
From: Marcelo Ricardo Leitner @ 2018-01-31 7:23 UTC (permalink / raw)
To: Eric Biggers
Cc: Xin Long, syzbot, davem, LKML, linux-sctp, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Tue, Jan 30, 2018 at 03:03:50PM -0800, Eric Biggers wrote:
> On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote:
> > On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
> > >
> > > from the log:
> > > [ 89.451366] FAULT_INJECTION: forcing a failure.^M
> > > [ 89.451366] name failslab, interval 1, probability 0, space 0,
> > > times 0^M
> > > [ 89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> > > +4.15.0-rc3-next-20171214+ #67^M
> > > [ 89.451377] Hardware name: Google Google Compute Engine/Google
> > > Compute Engine, BIOS
> > > +Google 01/01/2011^M
> > > [ 89.451380] Call Trace:^M
> > > [ 89.451395] dump_stack+0xe9/0x14b^M
> > > [ 89.451408] should_fail+0x1e5/0x220^M
> > > [ 89.451419] should_failslab+0x73/0x90^M
> > > [ 89.451428] __kmalloc+0x63/0x730^M
> > > [ 89.451439] ? rcu_read_lock_sched_held+0x74/0x80^M
> > > [ 89.451446] ? __kmalloc+0x4ac/0x730^M
> > > [ 89.451452] ? sctp_stream_alloc_in+0x2f/0x100^M
> > > [ 89.451464] sctp_stream_alloc_in+0x2f/0x100^M
> > > [ 89.451473] sctp_stream_init+0xfa/0x140^M
> > > [ 89.451485] sctp_process_init+0x676/0xc50^M
> > >
> > > this is what caused the panic later, because in the error path we free
> > > out but don't zero outcnt. This patch should fix it. Can you please
> > > try it? Thanks
> > >
> > > ----8<---
> > >
> > > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > > index 06b644dd858c..50ab09029f00 100644
> > > --- a/net/sctp/stream.c
> > > +++ b/net/sctp/stream.c
> > > @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
> > > sched->free(stream);
> > > kfree(stream->out);
> > > stream->out = NULL;
> > > + stream->outcnt = 0;
> > > out:
> > > return ret;
> > > }
> >
> > In case it can't be verified due to no reproducer yet, I modified some
> > code in sctp_stream_init() to confirm Marcelo's deduction:
> > - i = sctp_stream_alloc_in(stream, incnt, gfp);
> > + i = 1;
> > if (i) {
> > ret = -ENOMEM;
> > goto free;
> >
> > And got the same call trace as the mail:
> >
> > [ 301.488065] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000008
> > [ 301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
> > [ 301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
> > [ 301.489372] Oops: 0000 [#1] SMP
> > [...]
> > [ 301.497647] Call Trace:
> > [ 301.497812] <IRQ>
> > [ 301.497955] sctp_association_free+0xb8/0x210 [sctp]
> > [ 301.498306] sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
> > [ 301.498654] sctp_do_sm+0x9a/0x2d0 [sctp]
> > [ 301.498921] ? sctp_has_association+0x130/0x130 [sctp]
> > [ 301.499301] ? kernel_text_address+0xba/0xe0
> > [ 301.499615] ? check_usage_backwards+0x88/0x150
> > [ 301.499911] ? __lock_acquire+0x280/0x1080
> > [ 301.500200] ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
> > [ 301.500593] sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
> > [ 301.500923] sctp_rcv+0x9f5/0xbe0 [sctp]
> >
> > And Marcelo's patch could fix it.
> >
> > Since the "free:" part only works for if (i), maybe the patch can also do:
> > if (i) {
> > sched->free(stream);
> > kfree(stream->out);
> > stream->out = NULL;
> > stream->outcnt = 0;
> >
> > ret = -ENOMEM;
> > goto out;
> > }
> >
> > and remove the "free:" path.
>
> This crash seems to have stopped occurring now. I presume it was fixed by the
> following commit, so let's tell syzbot to close the bug:
Yes, thanks Eric.
>
> #syz fix: sctp: fix error path in sctp_stream_init
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-31 7:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <001a113fb1dcbf88120560cbbd81@google.com>
[not found] ` <20171221131333.GO6122@localhost.localdomain>
2017-12-22 5:31 ` BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free Xin Long
2018-01-30 23:03 ` Eric Biggers
2018-01-31 7:23 ` Marcelo Ricardo Leitner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).