linux-kernel - [PATCH] neighbour: purge nf_bridged skb from foreign device neigh

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Mon,  8 Jan 2024 16:50:12 +0800
From: Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
To: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	kernel@...nvz.org,
	Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
Subject: [PATCH] neighbour: purge nf_bridged skb from foreign device neigh

An skb can be added to a neigh->arp_queue while waiting for an arp
reply. Where original skb's skb->dev can be different to neigh's
neigh->dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh->arp_queue of the bridge.

There is no explicit mechanism that prevents the original skb->dev link
of such skb from being freed under us. For instance neigh_flush_dev does
not cleanup skbs from different device's neigh queue. But that original
link can be used and lead to crash on e.g. this stack:

arp_process
  neigh_update
    skb = __skb_dequeue(&neigh->arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb->dev = nf_bridge->physindev
              br_handle_frame_finish

So let's improve neigh_flush_dev to also purge skbs when device
equal to their skb->nf_bridge->physindev gets destroyed.

Signed-off-by: Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
---
I'm not fully sure, but likely it is:
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
---
 net/core/neighbour.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 552719c3bbc3d..47d2d52f17da3 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -39,6 +39,9 @@
 #include <linux/inetdevice.h>
 #include <net/addrconf.h>
 
+#include <linux/skbuff.h>
+#include <linux/netfilter_bridge.h>
+
 #include <trace/events/neigh.h>
 
 #define NEIGH_DEBUG 1
@@ -377,6 +380,28 @@ static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net,
 	}
 }
 
+static void neigh_purge_nf_bridge_dev(struct neighbour *neigh, struct net_device *dev)
+{
+	struct sk_buff_head *list = &neigh->arp_queue;
+	struct nf_bridge_info *nf_bridge;
+	struct sk_buff *skb, *next;
+
+	write_lock(&neigh->lock);
+	skb = skb_peek(list);
+	while (skb) {
+		nf_bridge = nf_bridge_info_get(skb);
+
+		next = skb_peek_next(skb, list);
+		if (nf_bridge && nf_bridge->physindev == dev) {
+			__skb_unlink(skb, list);
+			neigh->arp_queue_len_bytes -= skb->truesize;
+			kfree_skb(skb);
+		}
+		skb = next;
+	}
+	write_unlock(&neigh->lock);
+}
+
 static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev,
 			    bool skip_perm)
 {
@@ -393,6 +418,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev,
 		while ((n = rcu_dereference_protected(*np,
 					lockdep_is_held(&tbl->lock))) != NULL) {
 			if (dev && n->dev != dev) {
+				neigh_purge_nf_bridge_dev(n, dev);
 				np = &n->next;
 				continue;
 			}
-- 
2.43.0