* [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
@ 2018-09-07 22:08 dsahern
2018-09-17 4:14 ` David Ahern
0 siblings, 1 reply; 5+ messages in thread
From: dsahern @ 2018-09-07 22:08 UTC (permalink / raw)
To: netdev; +Cc: ndsouza, idosch, pablo, fw, David Ahern
From: David Ahern <dsahern@gmail.com>
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>
---
net/bridge/br_netfilter_hooks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index 6e0dc6bcd32a..37278dc280eb 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -835,7 +835,8 @@ static unsigned int ip_sabotage_in(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
- if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
+ if (skb->nf_bridge && !skb->nf_bridge->in_prerouting &&
+ !netif_is_l3_master(skb->dev)) {
state->okfn(state->net, state->sk, skb);
return NF_STOLEN;
}
--
2.11.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
2018-09-07 22:08 [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev dsahern
@ 2018-09-17 4:14 ` David Ahern
2018-09-17 8:29 ` Pablo Neira Ayuso
0 siblings, 1 reply; 5+ messages in thread
From: David Ahern @ 2018-09-17 4:14 UTC (permalink / raw)
To: dsahern, netdev, pablo, fw; +Cc: ndsouza, idosch
Pablo:
DaveM has this marked as waiting for upstream. Any comment on this patch?
Thanks,
David
On 9/7/18 3:08 PM, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> 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>
> ---
> net/bridge/br_netfilter_hooks.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
> index 6e0dc6bcd32a..37278dc280eb 100644
> --- a/net/bridge/br_netfilter_hooks.c
> +++ b/net/bridge/br_netfilter_hooks.c
> @@ -835,7 +835,8 @@ static unsigned int ip_sabotage_in(void *priv,
> struct sk_buff *skb,
> const struct nf_hook_state *state)
> {
> - if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
> + if (skb->nf_bridge && !skb->nf_bridge->in_prerouting &&
> + !netif_is_l3_master(skb->dev)) {
> state->okfn(state->net, state->sk, skb);
> return NF_STOLEN;
> }
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
2018-09-17 4:14 ` David Ahern
@ 2018-09-17 8:29 ` Pablo Neira Ayuso
0 siblings, 0 replies; 5+ messages in thread
From: Pablo Neira Ayuso @ 2018-09-17 8:29 UTC (permalink / raw)
To: David Ahern; +Cc: dsahern, netdev, fw, ndsouza, idosch
On Sun, Sep 16, 2018 at 09:14:42PM -0700, David Ahern wrote:
> Pablo:
>
> DaveM has this marked as waiting for upstream. Any comment on this patch?
Please, resend a Cc netfilter-devel@vger.kernel.org
Thanks David.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
2018-09-17 15:20 dsahern
@ 2018-09-20 16:25 ` Pablo Neira Ayuso
0 siblings, 0 replies; 5+ messages in thread
From: Pablo Neira Ayuso @ 2018-09-20 16:25 UTC (permalink / raw)
To: dsahern; +Cc: netdev, netfilter-devel, ndsouza, idosch, fw, David Ahern
On Mon, Sep 17, 2018 at 08:20:36AM -0700, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> 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.
Applied.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
@ 2018-09-17 15:20 dsahern
2018-09-20 16:25 ` Pablo Neira Ayuso
0 siblings, 1 reply; 5+ messages in thread
From: dsahern @ 2018-09-17 15:20 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: ndsouza, idosch, pablo, fw, David Ahern
From: David Ahern <dsahern@gmail.com>
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>
---
re-send adding netfilter
net/bridge/br_netfilter_hooks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index 6e0dc6bcd32a..37278dc280eb 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -835,7 +835,8 @@ static unsigned int ip_sabotage_in(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
- if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
+ if (skb->nf_bridge && !skb->nf_bridge->in_prerouting &&
+ !netif_is_l3_master(skb->dev)) {
state->okfn(state->net, state->sk, skb);
return NF_STOLEN;
}
--
2.11.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-09-20 22:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-07 22:08 [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev dsahern
2018-09-17 4:14 ` David Ahern
2018-09-17 8:29 ` Pablo Neira Ayuso
2018-09-17 15:20 dsahern
2018-09-20 16:25 ` Pablo Neira Ayuso
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.