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

Jiri Pirko
2016-06-22T12:47:00Z

Wed, Jun 22, 2016 at 02:21:29PM CEST, pabeni@redhat.com wrote:
>On Wed, 2016-06-22 at 12:55 +0200, Jiri Pirko wrote:
>> Wed, Jun 22, 2016 at 12:25:15PM CEST, pabeni@redhat.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.