Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2270617pxb; Mon, 11 Jan 2021 05:41:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwnkP83nbmS/Ah2lUcXH7rPy+tjSYzS5mzjmtiDiQk3/+cc+hXTFjIcwmdL8KSUzMzznC+Y X-Received: by 2002:a17:906:cb86:: with SMTP id mf6mr10627686ejb.57.1610372471996; Mon, 11 Jan 2021 05:41:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610372471; cv=none; d=google.com; s=arc-20160816; b=whEE9rVoDky5G2wMyMU1QZ/HTPu2dvADZEDC9y6kgYqg27Y5UIjuyjhC/u3doKnCsr 65l/ZgzCSvpZICZyPgCQHFd2wS5+EOtAGEyGrxv0j296dLAMqwHyrljMBthl0V7z43hf kGkQfpobkDghLShSBmasXaPDNmLYUISNIs1AzskFYQd0jvqRBRqSzYhnVqcPFbxMnvPb U+poBUa57Gf06zxl41P5BTFHrSg94Mf8TsgthWeNZlE8jry5v8hCU2S7QD9EUu0q5mOc cTm1iPCNxQMG/OG+UcRDwSZppTIYvdBQUgEMVOIhQDlZ1pGmxM5BRph6mpgs4XSZDXY8 vslA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=SoeA9c9ETS7DWyz3cFsSyCidhFPz7kC9202bxGt5WfY=; b=XfIMypcfg1PZETu1XtWkuylQNy4SOVXlwbHt3KSH1qwm8gdhsd1lSisqtASFteJFRe Krq2xq9EM4OlEfhcCBrkp9xgmxTWsfwG9PJU7kxsl7dEWZ0zQz2DbWpeagKY5v4FgYk3 ZDe4x3IO/NXiiqLz7wmqXmJ2HJQ2Cbgr75LPgZDw0rJqCL8PKqhHZ0CTRKE2BiU90yA2 P6zcwvyFZbx7a9gF424D+GvCrVWauH/God02dstKHnUMKeAXbDaiQA6ZMJOPyMCd1dS9 t6Ckmb6Fm+kMAaHvK8obDghP6GA1rEsCamB1JEsSbsYPXju/lmx2HyhXHBPv7K9EXGMK 0RYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AWKNQdSK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v17si6930910edr.428.2021.01.11.05.40.47; Mon, 11 Jan 2021 05:41:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AWKNQdSK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731560AbhAKNM6 (ORCPT + 99 others); Mon, 11 Jan 2021 08:12:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:59032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730897AbhAKNML (ORCPT ); Mon, 11 Jan 2021 08:12:11 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 035702250F; Mon, 11 Jan 2021 13:11:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1610370715; bh=kv7j7t0b3SZU4C2i21LlhxQz0FcvtjUII2WzLKI6S2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AWKNQdSKhZlfFEU8rzuVJLJPJDtbSGpI5nY1H1TvqQylrq8Bu+yEMsV1Fh3mL14QO 0MPS2puCO9/F+KyAyyevCMQk7BtPAy8Yik2/13pu+qUJqsR06R4f1i5t8zOItkdoTH fYA1clF36iu/QetRZ3k/EZy8XO1c5Z4w9yVyZ4ic= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Antoine Tenart , Alexander Duyck , Jakub Kicinski Subject: [PATCH 5.4 26/92] net-sysfs: take the rtnl lock when storing xps_cpus Date: Mon, 11 Jan 2021 14:01:30 +0100 Message-Id: <20210111130040.408172787@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210111130039.165470698@linuxfoundation.org> References: <20210111130039.165470698@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Antoine Tenart [ Upstream commit 1ad58225dba3f2f598d2c6daed4323f24547168f ] Two race conditions can be triggered when storing xps cpus, resulting in various oops and invalid memory accesses: 1. Calling netdev_set_num_tc while netif_set_xps_queue: - netif_set_xps_queue uses dev->tc_num as one of the parameters to compute the size of new_dev_maps when allocating it. dev->tc_num is also used to access the map, and the compiler may generate code to retrieve this field multiple times in the function. - netdev_set_num_tc sets dev->tc_num. If new_dev_maps is allocated using dev->tc_num and then dev->tc_num is set to a higher value through netdev_set_num_tc, later accesses to new_dev_maps in netif_set_xps_queue could lead to accessing memory outside of new_dev_maps; triggering an oops. 2. Calling netif_set_xps_queue while netdev_set_num_tc is running: 2.1. netdev_set_num_tc starts by resetting the xps queues, dev->tc_num isn't updated yet. 2.2. netif_set_xps_queue is called, setting up the map with the *old* dev->num_tc. 2.3. netdev_set_num_tc updates dev->tc_num. 2.4. Later accesses to the map lead to out of bound accesses and oops. A similar issue can be found with netdev_reset_tc. One way of triggering this is to set an iface up (for which the driver uses netdev_set_num_tc in the open path, such as bnx2x) and writing to xps_cpus in a concurrent thread. With the right timing an oops is triggered. Both issues have the same fix: netif_set_xps_queue, netdev_set_num_tc and netdev_reset_tc should be mutually exclusive. We do that by taking the rtnl lock in xps_cpus_store. Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Antoine Tenart Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/core/net-sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -1314,7 +1314,13 @@ static ssize_t xps_cpus_store(struct net return err; } + if (!rtnl_trylock()) { + free_cpumask_var(mask); + return restart_syscall(); + } + err = netif_set_xps_queue(dev, mask, index); + rtnl_unlock(); free_cpumask_var(mask);