diff options
author | David Ahern <dsahern@gmail.com> | 2018-09-17 08:20:36 -0700 |
---|---|---|
committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2018-09-20 18:24:14 +0200 |
commit | a173f066c7cfc031acb8f541708041e009fc9812 (patch) | |
tree | b8fdea4eee5fa7df3b4d60db301c9c5d683dffe1 /firmware | |
parent | 56ce3c5a50f4d8cc95361b1ec7f152006c6320d8 (diff) | |
download | linux-a173f066c7cfc031acb8f541708041e009fc9812.tar.gz linux-a173f066c7cfc031acb8f541708041e009fc9812.tar.bz2 linux-a173f066c7cfc031acb8f541708041e009fc9812.zip |
netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
For starters, the bridge netfilter code registers operations that
are invoked any time nh_hook is called. Specifically, ip_sabotage_in
watches for nested calls for NF_INET_PRE_ROUTING when a bridge is in
the stack.
Packet wise, the bridge netfilter hook runs first. br_nf_pre_routing
allocates nf_bridge, sets in_prerouting to 1 and calls NF_HOOK for
NF_INET_PRE_ROUTING. It's finish function, br_nf_pre_routing_finish,
then resets in_prerouting flag to 0 and the packet continues up the
stack. The packet eventually makes it to the VRF driver and it invokes
nf_hook for NF_INET_PRE_ROUTING in case any rules have been added against
the vrf device.
Because of the registered operations the call to nf_hook causes
ip_sabotage_in to be invoked. That function sees the nf_bridge on the
skb and that in_prerouting is not set. Thinking it is an invalid nested
call it steals (drops) the packet.
Update ip_sabotage_in to recognize that the bridge or one of its upper
devices (e.g., vlan) can be enslaved to a VRF (L3 master device) and
allow the packet to go through the nf_hook a second time.
Fixes: 73e20b761acf ("net: vrf: Add support for PREROUTING rules on vrf device")
Reported-by: D'Souza, Nelson <ndsouza@ciena.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'firmware')
0 files changed, 0 insertions, 0 deletions