vlan: don't deliver frames for unknown vlans to protocols
authorFlorian Zumbiehl <florz@florz.de>
Sun, 7 Oct 2012 15:51:58 +0000 (15:51 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 28 Oct 2012 17:14:15 +0000 (10:14 -0700)
commit2d2f242f248f19c4618bde9091d20416e2c9a1f6
tree5b15e35dde9a352bde196de7619b7268271df260
parent14a547a85a7fa2b6473eaa73b83e2055b476a5dc
vlan: don't deliver frames for unknown vlans to protocols

[ Upstream commit 48cc32d38a52d0b68f91a171a8d00531edc6a46e ]

6a32e4f9dd9219261f8856f817e6655114cfec2f made the vlan code skip marking
vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
there was an rx_handler, as the rx_handler could cause the frame to be received
on a different (virtual) vlan-capable interface where that vlan might be
configured.

As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
frames for unknown vlans to be delivered to the protocol stack as if they had
been received untagged.

For example, if an ipv6 router advertisement that's tagged for a locally not
configured vlan is received on an interface with macvlan interfaces attached,
macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
macvlan interfaces, which caused it to be passed to the protocol stack, leading
to ipv6 addresses for the announced prefix being configured even though those
are completely unusable on the underlying interface.

The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
rx_handler, if there is one, sees the frame unchanged, but afterwards,
before the frame is delivered to the protocol stack, it gets marked whether
there is an rx_handler or not.

Signed-off-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/if_vlan.h
net/8021q/vlan_core.c
net/core/dev.c