diff mbox series

[net] macvlan: add cond_resched() during multicast processing

Message ID 20200309225707.65351-1-maheshb@google.com
State Accepted
Delegated to: David Miller
Headers show
Series [net] macvlan: add cond_resched() during multicast processing | expand

Commit Message

The Rx bound multicast packets are deferred to a workqueue and
macvlan can also suffer from the same attack that was discovered
by Syzbot for IPvlan. This solution is not as effective as in
IPvlan. IPvlan defers all (Tx and Rx) multicast packet processing
to a workqueue while macvlan does this way only for the Rx. This
fix should address the Rx codition to certain extent.

Tx is still suseptible. Tx multicast processing happens when
.ndo_start_xmit is called, hence we cannot add cond_resched().
However, it's not that severe since the user which is generating
 / flooding will be affected the most.

Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Mahesh Bandewar <maheshb@google.com>

---
 drivers/net/macvlan.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

David Miller March 10, 2020, 1:02 a.m. UTC | #1
From: Mahesh Bandewar <maheshb@google.com>
Date: Mon,  9 Mar 2020 15:57:07 -0700

> The Rx bound multicast packets are deferred to a workqueue and
> macvlan can also suffer from the same attack that was discovered
> by Syzbot for IPvlan. This solution is not as effective as in
> IPvlan. IPvlan defers all (Tx and Rx) multicast packet processing
> to a workqueue while macvlan does this way only for the Rx. This
> fix should address the Rx codition to certain extent.
> 
> Tx is still suseptible. Tx multicast processing happens when
> .ndo_start_xmit is called, hence we cannot add cond_resched().
> However, it's not that severe since the user which is generating
>  / flooding will be affected the most.
> 
> Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>

Applied and queued up for -stable.
Eric Dumazet March 10, 2020, 1:09 a.m. UTC | #2
On 3/9/20 3:57 PM, Mahesh Bandewar wrote:
> The Rx bound multicast packets are deferred to a workqueue and
> macvlan can also suffer from the same attack that was discovered
> by Syzbot for IPvlan. This solution is not as effective as in
> IPvlan. IPvlan defers all (Tx and Rx) multicast packet processing
> to a workqueue while macvlan does this way only for the Rx. This
> fix should address the Rx codition to certain extent.

condition

> 
> Tx is still suseptible.

susceptible ? Not sure what you want to say here.

 Tx multicast processing happens when
> .ndo_start_xmit is called, hence we cannot add cond_resched().
> However, it's not that severe since the user which is generating
>  / flooding will be affected the most.
> 
> Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> 



Reviewed-by: Eric Dumazet <edumazet@google.com>
diff mbox series

Patch

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 81aa7adf4801..e7289d67268f 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -334,6 +334,8 @@  static void macvlan_process_broadcast(struct work_struct *w)
 		if (src)
 			dev_put(src->dev);
 		consume_skb(skb);
+
+		cond_resched();
 	}
 }