netdev - Re: [PATCH net-next] ipv6: protect skb->sk accesses from recursive dereference inside the stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Apr 2015 14:05:22 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Cong Wang <cwang@...pensource.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH net-next] ipv6: protect skb->sk accesses from recursive
 dereference inside the stack

On Thu, Apr 2, 2015, at 04:55, Cong Wang wrote:
> On Wed, Apr 1, 2015 at 5:27 PM, Eric Dumazet <eric.dumazet@...il.com>
> wrote:
> > On Wed, 2015-04-01 at 17:06 -0700, Cong Wang wrote:
> >
> >> Shouldn't these skb's be orphaned for tunnel cases? Or we still have
> >> to keep skb->sk for other valid use?
> >
> > skb should not be orphaned, until the very last stage.
> >
> > Many layers depend on this, really.
> >
> > Simply ask the question to yourself :
> >
> > What if I do not associate skb to a socket at first. What possibly
> > breaks ?
> >
> > orphaning skb just because they traverse a tunnel would be quite
> > horrible.
> >
> 
> I didn't make it clear, I meant to say "resetting the skb->sk to tunnel
> socket". I know sch_fq uses skb->sk for flow classification, but
> if skb->sk still points to the user-space socket, its meaning is already
> changed after encapsulation, with regarding to this, all traffic goes
> out of this tunnel should be one flow.

We cannot block/stop a tunnel submitting more packets into the stack via
its socket. We have to close the feedback loop directly to user space.
If we need this tunnel socket available it has to be passed either as an
additional field in sk_buff or via arguments down the stack.
In case of forwarding this works without skb->sk because we mostly
always run to completion and submit the packet in one softirq call.

> This also means ipv6 should not use any socket setting for routing
> lookup, since after resetting skb->sk in encapsulation skb's belong
> to one kernel socket which doesn't have any socket options set.

Yes, this is right. But besides xfrm6 layer I am currently looking after
I haven't seen problematic code here.

Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html