netdev - Re: [PATCH net 1/4] net-sysfs: take the rtnl lock when storing xps

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Dec 2020 16:30:41 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Antoine Tenart <atenart@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, pabeni@...hat.com,
        Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: [PATCH net 1/4] net-sysfs: take the rtnl lock when storing
 xps_cpus

On Thu, 17 Dec 2020 17:25:18 +0100 Antoine Tenart wrote:
> Callers to netif_set_xps_queue should take the rtnl lock. Failing to do
> so can lead to race conditions between netdev_set_num_tc and
> netif_set_xps_queue, triggering various oops:
> 
> - 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.
> 
> 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.
> 
> Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")

Let's CC Alex

> Signed-off-by: Antoine Tenart <atenart@...nel.org>

Two things: (a) is the datapath not exposed to a similar problem?
__get_xps_queue_idx() uses dev->tc_num in a very similar fashion.
Should we perhaps make the "num_tcs" part of the XPS maps which is
under RCU protection rather than accessing the netdev copy? 
(b) if we always take rtnl_lock, why have xps_map_mutex? Can we
rearrange things so that xps_map_mutex is sufficient?

> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index 999b70c59761..7cc15dec1717 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -1396,7 +1396,13 @@ static ssize_t xps_cpus_store(struct netdev_queue *queue,
>  		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);
>