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:	Wed, 1 Apr 2015 19:55:12 -0700
From:	Cong Wang <cwang@...pensource.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	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 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.

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.

As I said, there might be still some useful information from their
original skb->sk, I of course never audit all the skb->sk usage
in kernel.

Essentially, carrying L4 information to L2 does make things complicated
when udp tunnels are involved.
--
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