All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, jiri@resnulli.us
Subject: Re: [PATCH net-next] ipv6: protect skb->sk accesses from recursive dereference inside the stack
Date: Wed, 01 Apr 2015 20:57:52 +0200	[thread overview]
Message-ID: <1427914672.1808691.248212501.09E2ACED@webmail.messagingengine.com> (raw)
In-Reply-To: <20150401.144036.1354401396349418295.davem@davemloft.net>



On Wed, Apr 1, 2015, at 20:40, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > In case we do need more specific fragmentation setup semantics we would
> > need to go with Jiri's approach. Currently we don't care about sk_mc_loop
> > for kernel sockets, so it is easy to just shut them up. Other options
> > are safe as well.
> > 
> > Please review carefully!
> 
> As a short term solution I guess this is fine.
> 
> I'll let this sit for a day or two so others can review the change.

Ok, thanks!

We seem to have the same problem with skb->ignore_df which we
conditionally set by user request but multiple layer (e.g. tunnels) do
evaluate this boolean during stack traversal. IPv4 seems to be impacted
here as well, but I have to do more research on that. Maybe the
semantics seem to be wanted?

Bye,
Hannes

  reply	other threads:[~2015-04-01 18:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 15:07 [PATCH net-next] ipv6: protect skb->sk accesses from recursive dereference inside the stack Hannes Frederic Sowa
2015-04-01 18:40 ` David Miller
2015-04-01 18:57   ` Hannes Frederic Sowa [this message]
2015-04-01 19:26     ` David Miller
2015-04-02  0:06 ` Cong Wang
2015-04-02  0:27   ` Eric Dumazet
2015-04-02  0:35     ` Hannes Frederic Sowa
2015-04-02  0:48       ` Eric Dumazet
2015-04-02  0:56         ` Hannes Frederic Sowa
2015-04-02  1:53           ` Eric Dumazet
2015-04-02 11:34             ` Hannes Frederic Sowa
2015-04-02 16:24               ` David Miller
2015-04-02  2:55     ` Cong Wang
2015-04-02 12:05       ` Hannes Frederic Sowa
2015-04-06 20:14 ` David Miller

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=1427914672.1808691.248212501.09E2ACED@webmail.messagingengine.com \
    --to=hannes@stressinduktion.org \
    --cc=davem@davemloft.net \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    /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.