netdev - Re: [PATCH v2] ip6_tunnel: Clear IP6CB in ip6_tnl

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] [day] [month] [year] [list]

Message-Id: <20161031.141849.2021537115231143799.davem@davemloft.net>
Date:   Mon, 31 Oct 2016 14:18:49 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     shmulik.ladkani@...il.com
Cc:     elicooper@....com, tom@...bertland.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2] ip6_tunnel: Clear IP6CB in ip6_tnl_xmit() after
 encapsulation

From: Shmulik Ladkani <shmulik.ladkani@...il.com>
Date: Fri, 28 Oct 2016 19:07:57 +0300

> On Fri, 28 Oct 2016 13:13:45 +0800 Eli Cooper <elicooper@....com> wrote:
>> Maybe we
>> should clear IP6CB in ip6tunnel_xmit(), rather than in every tunnel's codes?
> 
> This seems reasonable.
> 
> A potential issue might be whether it needs to be done earlier, although
> I've reviewed current versions of both 'ip6_tnl_xmit' and
> 'udp_tunnel6_xmit_skb' and it looks okay. But please verify.
> 
>> By the way, I don't see any point in setting IPCB(skb)->flags in
>> udp_tunnel6_xmit_skb(). It will not be interpreted as IPCB any further
>> past ip6tunnel_xmit(), even if it were not cleared. Plus, nothing seems
>> to use these flags anyway.
> 
> This seems right.
> 
> It was introduced in 6a93cc9052 "udp-tunnel: Add a few more UDP tunnel APIs".
> 
> If you checkout that tree, you'll notice same treatment to
> IPCB(skb)->opt and IPCB(skb)->flags in l2tp_xmit_skb... maybe it was
> just copied ;-)

I think for now, we should clear IP6CB in ip6tunnel_xmit()
unconditionally, and remove the IPCB() stuff from the UDP tunneling
code.

If we need some kind of preservation of some of the IP6CB(skb)->flag
bits for whatever reason, we can add that later.  Right now that
code was producing essentially garbage.