diff options
author | Florian Zumbiehl <florz@florz.de> | 2012-10-07 15:51:58 +0000 |
---|---|---|
committer | Ben Hutchings <ben@decadent.org.uk> | 2012-10-30 23:26:34 +0000 |
commit | 16e23aa20ef67e5a97347aecbeae843e72149a68 (patch) | |
tree | 4a4ea8ee6efbcc8e980cda7e810ec0cf48017503 /include/target | |
parent | 380fd8550acc9c04fb2b7835a9663b5a0e53b840 (diff) |
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: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'include/target')
0 files changed, 0 insertions, 0 deletions