From: Simon Horman <horms@kernel.org>
To: Norbert Szetei <norbert@doyensec.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Kees Cook <kees@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: xps: reject an out of range traffic class
Date: Wed, 16 Sep 2026 11:31:52 +0100 [thread overview]
Message-ID: <20260916103152.GA51261@horms.kernel.org> (raw)
In-Reply-To: <CE030A45-D573-4310-8761-01431156F0D6@doyensec.com>
On Sat, Sep 12, 2026 at 08:01:06AM +0200, Norbert Szetei wrote:
> Only the entries below dev->num_tc are valid in dev->tc_to_txq[], and
> dev->prio_tc_map[] may only name classes below it. netdev_set_num_tc()
> lowers dev->num_tc without touching either array.
>
> netdev_txq_to_tc() walks all TC_MAX_QUEUE slots and
> netdev_get_prio_tc_map() returns the entry as it stands, so a leftover
> entry is handed out as a traffic class >= dev->num_tc. Taking that
> class from netdev_txq_to_tc(), __netif_set_xps_queue() rejects only a
> negative one and indexes an XPS map sized for dev->num_tc classes:
>
> tci = j * num_tc + tc;
> RCU_INIT_POINTER(new_dev_maps->attr_map[tci], map);
>
> Any caller that lowers num_tc leaves such entries behind, and
> mqprio_destroy() tears down with netdev_set_num_tc(dev, 0) rather than
> netdev_reset_tc(). After mqprio with 8 classes then 1, tc_to_txq[1..7]
> still describe txq 1..7. The splat is from an XPS write to txq 2:
>
> BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1eb9/0x2440
> Write of size 8 at addr ffff888110e978d8 by task xps_oob/573
> __netif_set_xps_queue+0x1eb9/0x2440
> xps_rxqs_store+0x24d/0x360
> netdev_queue_attr_store+0x61/0x90
> Allocated by task 573:
> __kmalloc_noprof+0x246/0x6c0
> __netif_set_xps_queue+0x8ca/0x2440
> The buggy address is located 0 bytes to the right of
> allocated 88-byte region [ffff888110e97880, ffff888110e978d8)
I think it would be useful to provide the stack trace with line numbers
decoded. This can be done using scripts/decode_stacktrace.sh
And perhaps be a bit more explicit in the description about how
an overrun of attr_map occurs; I believe that is what
the splat is telling us has happened.
>
> Reject a class the map has no room for.
>
> Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
> Assisted-by: LLM
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> ---
> v2:
> - bound the class in __netif_set_xps_queue() instead of clearing
> dev->tc_to_txq[]/dev->prio_tc_map[] in netdev_set_num_tc(), per the
> Sashiko review of v1
> - dropped the memory-ordering claim from the changelog
> - retitled
> v1: https://lore.kernel.org/netdev/16E3A318-5532-4B5E-8D03-86D21B463A2D@doyensec.com/
...
prev parent reply other threads:[~2026-09-16 10:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 6:01 [PATCH net v2] net: xps: reject an out of range traffic class Norbert Szetei
2026-09-16 10:31 ` Simon Horman [this message]
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=20260916103152.GA51261@horms.kernel.org \
--to=horms@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=norbert@doyensec.com \
--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.