Re: [PATCH net] net: xps: re-validate the queue index after switching to the subordinate device

[Antoine Tenart <atenart@kernel.org>]

On Wed, Oct 21, 2026 at 11:55:55PM +0800, Dudu Lu wrote:
> __netif_set_xps_queue() reassigns dev to the subordinate device
> (netdev_get_tx_queue(dev, index)->sb_dev) but keeps using index, which
> was only validated against the ORIGINAL device's queue count.  A
> subordinate with fewer TX queues than the parent's index then overflows
> sb_dev->_tx[] / the XPS map:
> 
>   BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x178c/0x1ee8
>   Write of size 4 at addr ffff000005d3fae0 by task A-26-F1-S2/162
>    __netif_set_xps_queue+0x178c/0x1ee8
>    netif_set_xps_queue+0x38/0x58
>    xps_cpus_store+0x1dc/0x2b8
> 
> The store is netdev_queue_numa_node_write() on sub->_tx[index].  The
> top-of-function WARN_ON_ONCE(index >= dev->num_tx_queues) only checks the
> parent and is a debug assertion.  Re-check index against the device that
> is actually indexed once dev has been rebound.
> 
> Note this is a different defect from the "reject an out of range traffic
> class" guard (4da3b7b8b50f), which bounds tc, not index.
> 
> Fixes: ffcfe25bb50f ("net: Add support for subordinate device traffic classes")
> Assisted-by: LLM
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
> ---
> 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 (identity established by disassembling both kernels: same store, same
> target offset #0x160).  The guest has no SR-IOV NIC, so the reproducer stands
> in for that hardware with a small module that binds an sb_dev the same way
> netdev_bind_sb_channel_queue() does for i40e/ixgbe.  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.  An sb_dev is bound in-tree by
> netdev_bind_sb_channel_queue(), which the i40e and ixgbe SR-IOV paths call
> when a VF's channel is bound to the PF.  The QEMU guest used for the
> reproducer has no SR-IOV NIC, so the sb_dev binding was set up 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 | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e76762e29360..d5ce25144806 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2900,6 +2900,14 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  		/* If queue belongs to subordinate dev use its map */
>  		dev = netdev_get_tx_queue(dev, index)->sb_dev ? : dev;
>  
> +		/* dev may now be the subordinate device, whose queue
> +		 * count can be smaller than the parent's.  index was only
> +		 * validated against the parent above, so re-check it before

The check is a WARN, not really validating against oob.

> +		 * it is used to index the (possibly different) dev->_tx[].
> +		 */
> +		if (index >= dev->real_num_tx_queues)
> +			return -EINVAL;

I don't know that area well but my understanding is while the mapping is
stored on the sb_dev, it points to queues on the dev; this would reject
valid configurations.

> +
>  		tc = netdev_txq_to_tc(dev, index);
>  		if (tc < 0 || tc >= num_tc)
>  			return -EINVAL;

Shouldn't netdev_queue_numa_node_write operate on the dev txqs instead
of the sb_dev ones?