netdev - Re: [PATCH net] net: avoid vlan ptype specific match to be leaked on real device

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]

Message-ID: <20160622124050.GD2068@nanopsycho.orion>
Date:	Wed, 22 Jun 2016 14:40:50 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	Paolo Abeni <pabeni@...hat.com>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Jiri Pirko <jiri@...lanox.com>,
	Alexander Duyck <aduyck@...antis.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net] net: avoid vlan ptype specific match to be leaked on
 real device

Wed, Jun 22, 2016 at 02:21:29PM CEST, pabeni@...hat.com wrote:
>On Wed, 2016-06-22 at 12:55 +0200, Jiri Pirko wrote:
>> Wed, Jun 22, 2016 at 12:25:15PM CEST, pabeni@...hat.com wrote:
>> >Before the commit 0dfe17823945 ("net: vlan: goto another_round
>> >instead of calling __netif_receive_skb"), on tagged skb ingress,
>> >ptype specific protocol matches were delivered only to the
>> >related vlan device, if any.
>> >After said commit, jumping back to the 'another_round' label, allows
>> >the later ptype specific check to match both orig_dev and skb->dev,
>> >delivering the skb to both the vlan device and the underlying
>> >device.
>> >This cause i.e. packet sockets bound to a specific protocol type on
>> >one of said devices to receive also frames really targeting the
>> >other device.
>> >This commit resets orig_dev before performing another round due to
>> >vlan processing, allowing the skb to be delivered once again only
>> >to the vlan specific ptypes.
>> 
>> I don't get why vlan should behave differently in this comparing to
>> other stacked devices like bond/team/br etc.
>> 
>> Could you please explain?
>
>vlan behavior has changed with the commit 0dfe17823945 (which is old,
>but still...), this patch is trying to restore the old one.
>
>The new behavior fouls existing applications which where expecting ptype
>specific match to be delivered only on the relevant device. 

The patch only unified the behaviour so everyone know what to expect
regardless of the device type.


>
>AFAIC jumping back to the 'another_round' is possible for team, bond,
>macvlan, macsec and ipvlan device, beyond vlan devices. I think the
>latter should be treated differently, beyond history reasons, because
>the vlan device processing, stripping the vlan tag, actually changes the
>ethernet type present into the ethernet header in respect to the wire
>packet layout; strict match on that value should give different results
>before and after vlan stripping.

The vlan header stripping happens before all of this, either in HW or
skb_vlan_untag, so you can never match on that.