From: Simon Horman <horms@kernel.org>
To: Kohei Enju <kohei@enjuk.jp>
Cc: andrew+netdev@lunn.ch, anthony.l.nguyen@intel.com,
davem@davemloft.net, edumazet@google.com,
intel-wired-lan@lists.osuosl.org, jedrzej.jagielski@intel.com,
kohei.enju@gmail.com, kuba@kernel.org,
mateusz.palczewski@intel.com, netdev@vger.kernel.org,
pabeni@redhat.com, przemyslaw.kitszel@intel.com,
przemyslawx.patynowski@intel.com, witoldx.fijalkowski@intel.com
Subject: Re: [Intel-wired-lan] [PATCH v1 iwl-net] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
Date: Tue, 17 Feb 2026 16:02:42 +0000 [thread overview]
Message-ID: <aZSRIh9Xz2q-PUaS@horms.kernel.org> (raw)
In-Reply-To: <20260216144457.19871-1-kohei@enjuk.jp>
On Mon, Feb 16, 2026 at 02:44:57PM +0000, Kohei Enju wrote:
> On Mon, 16 Feb 2026 13:19:09 +0000, Simon Horman wrote:
>
> > > @@ -345,19 +344,19 @@ static void iavf_get_ethtool_stats(struct net_device *netdev,
> > > iavf_add_ethtool_stats(&data, adapter, iavf_gstrings_stats);
> > >
> > > rcu_read_lock();
> > > - /* As num_active_queues describe both tx and rx queues, we can use
> > > - * it to iterate over rings' stats.
> > > + /* Use num_tx_queues to report stats for the maximum number of queues.
> > > + * Queues beyond num_active_queues will report zero.
> > > */
> > > - for (i = 0; i < adapter->num_active_queues; i++) {
> > > - struct iavf_ring *ring;
> > > + for (i = 0; i < netdev->num_tx_queues; i++) {
> > > + struct iavf_ring *tx_ring = NULL, *rx_ring = NULL;
> > >
> > > - /* Tx rings stats */
> > > - ring = &adapter->tx_rings[i];
> > > - iavf_add_queue_stats(&data, ring);
> > > + if (i < adapter->num_active_queues) {
> >
> > Hi Enju-san,
>
> Hi Horman-san, thank you for reviewing!
>
> >
> > If I understand things correctly, in the scenario described in the patch
> > description, num_active_queues will be 8 here.
>
> Yes.
>
> >
> > Won't that result in an overflow?
>
> I think it won't overflow.
>
> In Thread 1, iavf_set_channels(), which allocates {tx,rx}_rings and
> updates num_active_queues, is executed under netdev lock. Therefore
> Thread 3, which is also executed under the netdev lock, sees updated
> num_active_queues and {tx,rx}_rings.
>
> The scenario flow lacked netdev_(un)lock, my bad.
>
> Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)
> netdev_lock()
> iavf_set_channels()
> ...
> iavf_alloc_queues()
> -> alloc {tx,rx}_rings
> -> num_active_queues = 8
> iavf_schedule_finish_config()
> netdev_unlock()
> netdev_lock()
> iavf_get_sset_count()
> real_num_tx_queues: 1
> -> buffer for 1 queue
> iavf_get_ethtool_stats()
> num_active_queues: 8
> -> out-of-bounds!
> netdev_unlock()
> iavf_finish_config()
> netdev_lock()
> -> real_num_tx_queues = 8
> netdev_unlock()
Thanks, and sorry for missing that the first time around.
With that clarified in my mind this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Kohei Enju <kohei@enjuk.jp>
Cc: andrew+netdev@lunn.ch, anthony.l.nguyen@intel.com,
davem@davemloft.net, edumazet@google.com,
intel-wired-lan@lists.osuosl.org, jedrzej.jagielski@intel.com,
kohei.enju@gmail.com, kuba@kernel.org,
mateusz.palczewski@intel.com, netdev@vger.kernel.org,
pabeni@redhat.com, przemyslaw.kitszel@intel.com,
przemyslawx.patynowski@intel.com, witoldx.fijalkowski@intel.com
Subject: Re: [PATCH v1 iwl-net] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
Date: Tue, 17 Feb 2026 16:02:42 +0000 [thread overview]
Message-ID: <aZSRIh9Xz2q-PUaS@horms.kernel.org> (raw)
In-Reply-To: <20260216144457.19871-1-kohei@enjuk.jp>
On Mon, Feb 16, 2026 at 02:44:57PM +0000, Kohei Enju wrote:
> On Mon, 16 Feb 2026 13:19:09 +0000, Simon Horman wrote:
>
> > > @@ -345,19 +344,19 @@ static void iavf_get_ethtool_stats(struct net_device *netdev,
> > > iavf_add_ethtool_stats(&data, adapter, iavf_gstrings_stats);
> > >
> > > rcu_read_lock();
> > > - /* As num_active_queues describe both tx and rx queues, we can use
> > > - * it to iterate over rings' stats.
> > > + /* Use num_tx_queues to report stats for the maximum number of queues.
> > > + * Queues beyond num_active_queues will report zero.
> > > */
> > > - for (i = 0; i < adapter->num_active_queues; i++) {
> > > - struct iavf_ring *ring;
> > > + for (i = 0; i < netdev->num_tx_queues; i++) {
> > > + struct iavf_ring *tx_ring = NULL, *rx_ring = NULL;
> > >
> > > - /* Tx rings stats */
> > > - ring = &adapter->tx_rings[i];
> > > - iavf_add_queue_stats(&data, ring);
> > > + if (i < adapter->num_active_queues) {
> >
> > Hi Enju-san,
>
> Hi Horman-san, thank you for reviewing!
>
> >
> > If I understand things correctly, in the scenario described in the patch
> > description, num_active_queues will be 8 here.
>
> Yes.
>
> >
> > Won't that result in an overflow?
>
> I think it won't overflow.
>
> In Thread 1, iavf_set_channels(), which allocates {tx,rx}_rings and
> updates num_active_queues, is executed under netdev lock. Therefore
> Thread 3, which is also executed under the netdev lock, sees updated
> num_active_queues and {tx,rx}_rings.
>
> The scenario flow lacked netdev_(un)lock, my bad.
>
> Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)
> netdev_lock()
> iavf_set_channels()
> ...
> iavf_alloc_queues()
> -> alloc {tx,rx}_rings
> -> num_active_queues = 8
> iavf_schedule_finish_config()
> netdev_unlock()
> netdev_lock()
> iavf_get_sset_count()
> real_num_tx_queues: 1
> -> buffer for 1 queue
> iavf_get_ethtool_stats()
> num_active_queues: 8
> -> out-of-bounds!
> netdev_unlock()
> iavf_finish_config()
> netdev_lock()
> -> real_num_tx_queues = 8
> netdev_unlock()
Thanks, and sorry for missing that the first time around.
With that clarified in my mind this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-02-17 16:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 19:14 [Intel-wired-lan] [PATCH v1 iwl-net] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats() Kohei Enju
2026-02-14 19:14 ` Kohei Enju
2026-02-16 13:19 ` [Intel-wired-lan] " Simon Horman
2026-02-16 13:19 ` Simon Horman
2026-02-16 14:44 ` [Intel-wired-lan] " Kohei Enju
2026-02-16 14:44 ` Kohei Enju
2026-02-16 15:17 ` [Intel-wired-lan] " Kohei Enju
2026-02-16 15:17 ` Kohei Enju
2026-02-17 16:02 ` Simon Horman [this message]
2026-02-17 16:02 ` Simon Horman
2026-02-18 5:39 ` [Intel-wired-lan] " Przemek Kitszel
2026-02-18 5:39 ` Przemek Kitszel
2026-02-18 6:31 ` [Intel-wired-lan] " Kohei Enju
2026-02-18 6:31 ` Kohei Enju
2026-02-18 8:00 ` [Intel-wired-lan] " Paul Menzel
2026-03-19 9:14 ` Romanowski, Rafal
2026-03-19 9:14 ` Romanowski, Rafal
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=aZSRIh9Xz2q-PUaS@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jedrzej.jagielski@intel.com \
--cc=kohei.enju@gmail.com \
--cc=kohei@enjuk.jp \
--cc=kuba@kernel.org \
--cc=mateusz.palczewski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=przemyslawx.patynowski@intel.com \
--cc=witoldx.fijalkowski@intel.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.