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]

Date:	Wed, 22 Jun 2016 14:21:29 +0200
From:	Paolo Abeni <pabeni@...hat.com>
To:	Jiri Pirko <jiri@...nulli.us>
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

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. 

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.

Paolo