From: Dudu Lu <phx0fer@gmail.com>
To: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
pabeni@redhat.com
Cc: netdev@vger.kernel.org
Subject: [PATCH net] net: xps: re-validate the queue index after switching to the subordinate device
Date: Wed, 21 Oct 2026 23:55:55 +0800 [thread overview]
Message-ID: <20261021155555.68167-1-phx0fer@gmail.com> (raw)
__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
+ * it is used to index the (possibly different) dev->_tx[].
+ */
+ if (index >= dev->real_num_tx_queues)
+ return -EINVAL;
+
tc = netdev_txq_to_tc(dev, index);
if (tc < 0 || tc >= num_tc)
return -EINVAL;
next reply other threads:[~2026-10-21 15:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 15:55 Dudu Lu [this message]
2026-10-23 9:49 ` [PATCH net] net: xps: re-validate the queue index after switching to the subordinate device Antoine Tenart
2026-10-25 17:47 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261021155555.68167-1-phx0fer@gmail.com \
--to=phx0fer@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.