| Message ID | 20201217162521.1134496-4-atenart@kernel.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | net-sysfs: fix race conditions in the xps code | expand |
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index 65886bfbf822..62ca2f2c0ee6 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -1499,10 +1499,17 @@ static ssize_t xps_rxqs_store(struct netdev_queue *queue, const char *buf, return err; } + if (!rtnl_trylock()) { + bitmap_free(mask); + return restart_syscall(); + } + cpus_read_lock(); err = __netif_set_xps_queue(dev, mask, index, true); cpus_read_unlock(); + rtnl_unlock(); + bitmap_free(mask); return err ? : len; }
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_rxqs in a concurrent thread. With the right timing an oops is triggered. Fixes: 8af2c06ff4b1 ("net-sysfs: Add interface for Rx queue(s) map per Tx queue") Signed-off-by: Antoine Tenart <atenart@kernel.org> --- net/core/net-sysfs.c | 7 +++++++ 1 file changed, 7 insertions(+)