Re: [PATCH net] net: xps: bound the cleanup loop by the old map's num_tc

[Antoine Tenart <atenart@kernel.org>]

On Wed, Oct 21, 2026 at 11:55:38PM +0800, Dudu Lu wrote:
> __netif_set_xps_queue() walks the OLD dev_maps to free its entries.  The
> per-row trip count uses the NEW num_tc while the row stride uses the OLD
> dev_maps->num_tc, so when dev->num_tc was raised without rebuilding the
> XPS map the last row indexes attr_map[] past the allocation:
> 
>   BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1458/0x1ee8
>   Read of size 8 at addr ffff000014f69458 by task insmod/112
> 
> The loop frees entries in dev_maps, so both the trip count and the stride
> must come from dev_maps->num_tc.  The map is sized
> XPS_CPU_DEV_MAPS_SIZE(old num_tc)/XPS_RXQ_DEV_MAPS_SIZE(old num_tc, ...),
> so iterating the new (larger) num_tc reads past the end.
> 
> Fixes: 255c04a87f43 ("net: embed num_tc in the xps maps")
> Assisted-by: LLM
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>

Reviewed-by: Antoine Tenart <atenart@kernel.org>

> ---
> Tested base
> -----------
> Detected on Linux 7.3-rc4 (commit 93f51579e7df), arm64 QEMU guest.
> Re-checked against mainline f47d223627f8 (v7.3-341): the affected code
> is unchanged between the two, so the bug is still present there.
> Checked against linux-next next-20261021 (commit 9a482184d910): the
> affected code is unchanged there as well, so the bug is still present in
> linux-next too.
> 
> Reproducer status
> -----------------
> A reproducer was written and executed on an arm64 QEMU guest (KASAN); it
> fires at the claimed sink, and still fires on a kernel built with 4da3b7b8b50f
> applied.  The guest has no ndo_setup_tc NIC, so the reproducer stands in for
> that hardware with a small module that raises dev->num_tc the same way an
> in-tree driver does.  The reproducer source is not posted here per
> Documentation/process/security-bugs.rst; it is available on request.
> 
> Triggering conditions
> ---------------------
> CAP_NET_ADMIN to set the XPS mask.  dev->num_tc is raised in-tree by the
> drivers that implement ndo_setup_tc (the Intel i40e/ice/ixgbe/iavf, mlx5
> and mvneta families, among others) and by the mqprio/taprio qdiscs.  The
> QEMU guest used for the reproducer has no such NIC, so the num_tc change
> was driven through a small module; the defect itself is reached in-tree
> on that hardware.
> 
> Notes
> -----
> Built and checkpatch-clean: this patch was applied on top of 7.3-rc4
> (commit 93f51579e7df) and a full arm64 kernel (defconfig) was built with
> it -- no new warnings or errors.  scripts/checkpatch.pl reports 0 errors,
> 0 warnings.
> 
>  net/core/dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e76762e29360..3023f0ca4713 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3003,7 +3003,7 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  		goto out_no_old_maps;
>  
>  	for (j = 0; j < dev_maps->nr_ids; j++) {
> -		for (i = num_tc, tci = j * dev_maps->num_tc; i--; tci++) {
> +		for (i = dev_maps->num_tc, tci = j * dev_maps->num_tc; i--; tci++) {
>  			map = xmap_dereference(dev_maps->attr_map[tci]);
>  			if (!map)
>  				continue;