All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: "Robert Święcki" <robert@swiecki.net>
Cc: linux-sctp@vger.kernel.org, linux-kernel@vger.kernel.org,
	vyasevich@gmail.com
Subject: Re: panic in skb_push via sctp
Date: Mon, 01 Dec 2014 18:08:35 +0000	[thread overview]
Message-ID: <547CAEA3.3090906@redhat.com> (raw)
In-Reply-To: <CAP145pggcEUKz3QhDEGdzWZDusPfwJsZ8juqjbRr+8g6RxuJfA@mail.gmail.com>

On 12/01/2014 07:02 PM, Robert Święcki wrote:
> Thanks for looking into it. I can try with your patch, but no
> guarantees that the fuzzer will hit the same condition in some
> reasonable time-frame. Will get back in some time with results.

Ok, thanks!

> PS. If you think it's possible to create a repro (userland code) which
> can trigger this, I can give it a try.

Did by accident trinity create tunnels? It looks that upper layer
protocols (except SCTP) all allocate and reserve MAX_HEADER to
accommodate enough head room in worst case for possible tunnels.

> 2014-12-01 18:36 GMT+01:00 Daniel Borkmann <dborkman@redhat.com>:
>> On 12/01/2014 05:49 PM, Robert Święcki wrote:
>>>
>>> I don't have much more, cause my kernel is kASLRNized and gdb cannot
>>> handle that, but pasting output from kdb. Maybe somebody will be able
>>> to see something obvious.
>>>
>>>    <0>[93699.703244] skbuff: skb_under_panic: text:ffffffff83cff03e
>>> len:104 put:56 head:ffff8803bd804ec0 data:ffff8803bd804ebc tail:0x64
>>> end:0xc0 dev:<NULL>
>>
>>
>> Thanks for the report!
>>
>> On a first view, it looks like we should be using MAX_HEADER instead
>> of LL_MAX_HEADER here, could you try with the following patch:
>>
>> diff --git a/net/sctp/output.c b/net/sctp/output.c
>> index 42dffd4..fc5e45b 100644
>> --- a/net/sctp/output.c
>> +++ b/net/sctp/output.c
>> @@ -401,12 +401,12 @@ int sctp_packet_transmit(struct sctp_packet *packet)
>>          sk = chunk->skb->sk;
>>
>>          /* Allocate the new skb.  */
>> -       nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC);
>> +       nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
>>          if (!nskb)
>>                  goto nomem;
>>
>>          /* Make sure the outbound skb has enough header room reserved. */
>> -       skb_reserve(nskb, packet->overhead + LL_MAX_HEADER);
>> +       skb_reserve(nskb, packet->overhead + MAX_HEADER);
>>
>>          /* Set the owning socket so that we know where to get the
>>           * destination IP address.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <dborkman@redhat.com>
To: "Robert Święcki" <robert@swiecki.net>
Cc: linux-sctp@vger.kernel.org, linux-kernel@vger.kernel.org,
	vyasevich@gmail.com
Subject: Re: panic in skb_push via sctp
Date: Mon, 01 Dec 2014 19:08:35 +0100	[thread overview]
Message-ID: <547CAEA3.3090906@redhat.com> (raw)
In-Reply-To: <CAP145pggcEUKz3QhDEGdzWZDusPfwJsZ8juqjbRr+8g6RxuJfA@mail.gmail.com>

On 12/01/2014 07:02 PM, Robert Święcki wrote:
> Thanks for looking into it. I can try with your patch, but no
> guarantees that the fuzzer will hit the same condition in some
> reasonable time-frame. Will get back in some time with results.

Ok, thanks!

> PS. If you think it's possible to create a repro (userland code) which
> can trigger this, I can give it a try.

Did by accident trinity create tunnels? It looks that upper layer
protocols (except SCTP) all allocate and reserve MAX_HEADER to
accommodate enough head room in worst case for possible tunnels.

> 2014-12-01 18:36 GMT+01:00 Daniel Borkmann <dborkman@redhat.com>:
>> On 12/01/2014 05:49 PM, Robert Święcki wrote:
>>>
>>> I don't have much more, cause my kernel is kASLRNized and gdb cannot
>>> handle that, but pasting output from kdb. Maybe somebody will be able
>>> to see something obvious.
>>>
>>>    <0>[93699.703244] skbuff: skb_under_panic: text:ffffffff83cff03e
>>> len:104 put:56 head:ffff8803bd804ec0 data:ffff8803bd804ebc tail:0x64
>>> end:0xc0 dev:<NULL>
>>
>>
>> Thanks for the report!
>>
>> On a first view, it looks like we should be using MAX_HEADER instead
>> of LL_MAX_HEADER here, could you try with the following patch:
>>
>> diff --git a/net/sctp/output.c b/net/sctp/output.c
>> index 42dffd4..fc5e45b 100644
>> --- a/net/sctp/output.c
>> +++ b/net/sctp/output.c
>> @@ -401,12 +401,12 @@ int sctp_packet_transmit(struct sctp_packet *packet)
>>          sk = chunk->skb->sk;
>>
>>          /* Allocate the new skb.  */
>> -       nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC);
>> +       nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
>>          if (!nskb)
>>                  goto nomem;
>>
>>          /* Make sure the outbound skb has enough header room reserved. */
>> -       skb_reserve(nskb, packet->overhead + LL_MAX_HEADER);
>> +       skb_reserve(nskb, packet->overhead + MAX_HEADER);
>>
>>          /* Set the owning socket so that we know where to get the
>>           * destination IP address.

  reply	other threads:[~2014-12-01 18:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 16:49 panic in skb_push via sctp Robert Święcki
2014-12-01 16:49 ` Robert Święcki
2014-12-01 17:36 ` Daniel Borkmann
2014-12-01 17:36   ` Daniel Borkmann
2014-12-01 18:02   ` Robert Święcki
2014-12-01 18:02     ` Robert Święcki
2014-12-01 18:08     ` Daniel Borkmann [this message]
2014-12-01 18:08       ` Daniel Borkmann
2014-12-01 19:00       ` Robert Święcki
2014-12-01 19:00         ` Robert Święcki
2014-12-01 19:14         ` Daniel Borkmann
2014-12-01 19:14           ` Daniel Borkmann
2014-12-01 19:17           ` Robert Święcki
2014-12-01 19:17             ` Robert Święcki
2014-12-01 21:58             ` Daniel Borkmann
2014-12-01 21:58               ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547CAEA3.3090906@redhat.com \
    --to=dborkman@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=robert@swiecki.net \
    --cc=vyasevich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.