netfilter: nft_reject_bridge: don't use IP stack to reject traffic
commit523b929d5446c023e1219aa81455a8c766cac883
authorPablo Neira Ayuso <pablo@netfilter.org>
Sat, 25 Oct 2014 16:40:26 +0000 (25 18:40 +0200)
committerPablo Neira Ayuso <pablo@netfilter.org>
Fri, 31 Oct 2014 11:50:08 +0000 (31 12:50 +0100)
tree3ecc2b3ae4776fdf86c8d7c4322a8297b814754b
parent8bfcdf6671b1c8006c52c3eaf9fd1b5dfcf41c3d
netfilter: nft_reject_bridge: don't use IP stack to reject traffic

If the packet is received via the bridge stack, this cannot reject
packets from the IP stack.

This adds functions to build the reject packet and send it from the
bridge stack. Comments and assumptions on this patch:

1) Validate the IPv4 and IPv6 headers before further processing,
   given that the packet comes from the bridge stack, we cannot assume
   they are clean. Truncated packets are dropped, we follow similar
   approach in the existing iptables match/target extensions that need
   to inspect layer 4 headers that is not available. This also includes
   packets that are directed to multicast and broadcast ethernet
   addresses.

2) br_deliver() is exported to inject the reject packet via
   bridge localout -> postrouting. So the approach is similar to what
   we already do in the iptables reject target. The reject packet is
   sent to the bridge port from which we have received the original
   packet.

3) The reject packet is forged based on the original packet. The TTL
   is set based on sysctl_ip_default_ttl for IPv4 and per-net
   ipv6.devconf_all hoplimit for IPv6.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
net/bridge/br_forward.c
net/bridge/netfilter/nft_reject_bridge.c