Received-SPF: pass (google.com: domain of linux-kernel+bounces-19215-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
To: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	kernel@openvz.org,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Subject: [PATCH] neighbour: purge nf_bridged skb from foreign device neigh
Date: Mon,  8 Jan 2024 16:50:12 +0800
Message-ID: <20240108085232.95437-1-ptikhomirov@virtuozzo.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?UHBdBakAYuuPO8e28U3RRBd8S+GjH9JmuQejwVc4TeOHZ03qOTMyjfKC5sJw?=
 =?us-ascii?Q?IWtjTLY/ujAbM+FAPolc6cC0KAmvJ0rpA0G3oc8nr9glcGCO5w74GtECBfdO?=
 =?us-ascii?Q?MXXb9y091fSx5WQ8XtbfP9Jah9IUADSBpkIvkTvct7/ecQXiX1FCBb7zK6wj?=
 =?us-ascii?Q?shYWGBVBnBEY2dV1dkXLAwcHiMx1fwPPK9pDEvBA74K05eSxssLWFpGsFJj/?=
 =?us-ascii?Q?IS/6ZPV+DY2qlJFkoZK0StV6aPfMcwPVZ/Wsac4JH4KEwY/01a0nB8CQQe4w?=
 =?us-ascii?Q?X+6PEgEcWICltQPdGbq4ul9ydAjNqSft2QiVh/OCgwv+nvObeu+yr8Dx4frH?=
 =?us-ascii?Q?WJQhLAELSvG0mbtl5OikWf2Dm+Olh8IpiGC0xsZK37Xvn/djvv3sj2pJ+OYi?=
 =?us-ascii?Q?uWACspoTk+dDHBFLnt5gqdv8gwfHp8Uo8h9tTk6L8BAjBsntMBNHGaARUR/s?=
 =?us-ascii?Q?iedGcPrkiq3KTdQDfFc1tLkF3VvBwHi4B3AjBEZEKMO+vfUbJxKKlmkvUjr8?=
 =?us-ascii?Q?7XlLAul6Ku4ZHkdyPYSwVx+NSEa0kOGE5kwjSW4QY+yzFUlMnq2xZnZOiSa9?=
 =?us-ascii?Q?cKiEHYSo1ofrS9YWSNTcL6Lds9KMNluWy0Peu9PWe5dkvxKShwtcqhMVtR72?=
 =?us-ascii?Q?XyUOd9ZCrDLKNsZZRr9nad32SeEEzT8VlWcLxW6k4gI+qpkH6SMA79AZY77t?=
 =?us-ascii?Q?duwWxQg5IkOCnD5uwXZLmGqILWOt2QmdYpAx4ZID1hN+nHRFuU9ZcEH9dMJB?=
 =?us-ascii?Q?/WAes34UAbE7wVLkY+xhbTx9G09CZew2vjYBGYDXxvkUZ2gb3XcWYLrlT6bM?=
 =?us-ascii?Q?RNrNPhubC5ny4aeki60YtnqZoDMlZtZbdBFkWMqal8yVl/pweyDt3BfUC5o8?=
 =?us-ascii?Q?U56iB3f/HplalQZ42x+zDa4IT7RPOJLqCsOS58K5iHjfdXppycxsoUNO4bcB?=
 =?us-ascii?Q?fbZt0nxPb4mxkTwZrL2bdM6ybu3ct/bhJ+pRbpPDRTCzbeDgPeZKS4ur1ydR?=
 =?us-ascii?Q?2VDuNtJF+vNey7iKhrHXMQYm+Yq7xCZyU97fr6JjTd6LfsCl/p4xiDvH5MHU?=
 =?us-ascii?Q?iCY6TAaUycDs8m3oDdKi50NOyu1ewT4SDvML/qTp7NXYVe35sAhpTXMQAqqN?=
 =?us-ascii?Q?sWUt+Nd5ixFtFQDFLul9CfHfC/Xr3N6HrmScWytLe8KaRYNAdvtSOf87RCX8?=
 =?us-ascii?Q?4vHHx9praiOWlrGDCHC7m4BPhTnSVrJOup+GuVTE3BY/7FFCkN1qhf1ocwwi?=
 =?us-ascii?Q?Mn9vLaNBrbfHRzW5eiOIfhMN8n7oHs1OJZYtE2h39r/MRqYKHkuofc5aFHav?=
 =?us-ascii?Q?Q+TnnrAkp27pZSACBIPGgIeDGIw00TQiqXAHaQz7KslnYkbogyuK91yzeiHC?=
 =?us-ascii?Q?y/V4xdWGaKZw59OkjtBSt/Dl9XVbR1/ecdU8c959AV8RHNr0rAStkVuWDcN5?=
 =?us-ascii?Q?qILyT0FB+AEwqg0M1phD7ZRDPJjyOQx9dXdIvmmW5cGfBYsZ7Ror9xSMGLIe?=
 =?us-ascii?Q?tgn0PcbyfZijrlm1tVzWGd0Icwr7dLmvlfS8DBH8QNf15nRQvJ7nGGVLJx+2?=
 =?us-ascii?Q?2BPxmTpLcK/mqNk920yVyWvDKqaD01fZIefMJq6ddRI5igeBhvnyg+GHzKHj?=
 =?us-ascii?Q?r7RiuxjJtcOsgfFmOOYPMz+T2N+WRu8jP/RrEk6PzQkD3Yl2PC4mNFBDIDLN?=
 =?us-ascii?Q?u6xOMA=3D=3D?=
X-OriginatorOrg: virtuozzo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 16f3a349-4f93-49c6-6521-08dc10273035
X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB9003.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2024 08:52:47.9587
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: zzeq0G6ckRpmdmMocn4fWuFRmrO7meye/E+m4GwL7MJx9L0VR4Sbnj/gV3FSB5ZjYXFjBrfH2yZtPiUCh2qcEgKE3qukYeRq0m+B0sYa8Ng=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7678

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@virtuozzo.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