From patchwork Sat Mar 19 09:52:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Ziyang Xuan (William)" X-Patchwork-Id: 12786145 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B07FC433EF for ; Sat, 19 Mar 2022 09:34:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242598AbiCSJgR (ORCPT ); Sat, 19 Mar 2022 05:36:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234179AbiCSJgR (ORCPT ); Sat, 19 Mar 2022 05:36:17 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 538FC274296; Sat, 19 Mar 2022 02:34:56 -0700 (PDT) Received: from canpemm500006.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KLG036wLQzfYl1; Sat, 19 Mar 2022 17:33:23 +0800 (CST) Received: from localhost.localdomain (10.175.104.82) by canpemm500006.china.huawei.com (7.192.105.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 19 Mar 2022 17:34:54 +0800 From: Ziyang Xuan To: , , , CC: , , Subject: [PATCH net-next v3 1/3] net: ipvlan: fix potential UAF problem for phy_dev Date: Sat, 19 Mar 2022 17:52:37 +0800 Message-ID: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 X-Originating-IP: [10.175.104.82] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500006.china.huawei.com (7.192.105.130) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org There is a known scenario can trigger UAF problem for lower netdevice as following: Someone module puts the NETDEV_UNREGISTER event handler to a work, and lower netdevice is accessed in the work handler. But when the work is excuted, lower netdevice has been destroyed because upper netdevice did not get reference to lower netdevice correctly. Although it can not happen for ipvlan now because there is no way to access phy_dev outside ipvlan. But it is necessary to add the reference operation to phy_dev to avoid the potential UAF problem in the future. Signed-off-by: Ziyang Xuan --- drivers/net/ipvlan/ipvlan_main.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c index 696e245f6d00..dcdc01403f22 100644 --- a/drivers/net/ipvlan/ipvlan_main.c +++ b/drivers/net/ipvlan/ipvlan_main.c @@ -158,6 +158,10 @@ static int ipvlan_init(struct net_device *dev) } port = ipvlan_port_get_rtnl(phy_dev); port->count += 1; + + /* Get ipvlan's reference to phy_dev */ + dev_hold(phy_dev); + return 0; } @@ -665,6 +669,14 @@ void ipvlan_link_delete(struct net_device *dev, struct list_head *head) } EXPORT_SYMBOL_GPL(ipvlan_link_delete); +static void ipvlan_dev_free(struct net_device *dev) +{ + struct ipvl_dev *ipvlan = netdev_priv(dev); + + /* Get rid of the ipvlan's reference to phy_dev */ + dev_put(ipvlan->phy_dev); +} + void ipvlan_link_setup(struct net_device *dev) { ether_setup(dev); @@ -674,6 +686,7 @@ void ipvlan_link_setup(struct net_device *dev) dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE; dev->netdev_ops = &ipvlan_netdev_ops; dev->needs_free_netdev = true; + dev->priv_destructor = ipvlan_dev_free; dev->header_ops = &ipvlan_header_ops; dev->ethtool_ops = &ipvlan_ethtool_ops; }