public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Kohei Enju <kohei@enjuk.jp>
To: przemyslaw.kitszel@intel.com
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, kohei@enjuk.jp, kuba@kernel.org,
	netdev@vger.kernel.org, pabeni@redhat.com
Subject: Re: [PATCH v1 iwl-net] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
Date: Wed, 18 Feb 2026 06:31:03 +0000	[thread overview]
Message-ID: <20260218063103.10265-1-kohei@enjuk.jp> (raw)
In-Reply-To: <234a3e23-590e-4e55-a242-41a2fb377d22@intel.com>

On Wed, 18 Feb 2026 06:39:43 +0100, Przemek Kitszel wrote:

> On 2/14/26 20:14, Kohei Enju wrote:
> > iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the
> > value could change in runtime, we should use num_tx_queues instead.
> > 
> 
> [...]
> 
> > Use immutable num_tx_queues in all related functions to avoid the issue.
> > 
> > [1]
> >   BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270
> 
> [...]
> 
> Thank you very much Enju-san,
> this is a nice improvement!
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> 
> Side note: I'm working on enabling 256 queues for iavf, what means

Cool, and thank you for reviewing!

> changing the reported max number of queues, what finally means screens
> of zero stats printed, unfortunate, but better be correct that pretty ;)

Indeed.

> 
> > 
> > Fixes: 64430f70ba6f ("iavf: Fix displaying queue statistics shown by ethtool")
> > Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> > ---
> >   .../net/ethernet/intel/iavf/iavf_ethtool.c    | 31 +++++++++----------
> >   1 file changed, 15 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
> > index 6ff3842a1ff1..98bec3afc200 100644
> > --- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
> > +++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
> > @@ -313,14 +313,13 @@ static int iavf_get_sset_count(struct net_device *netdev, int sset)
> >   {
> >   	/* Report the maximum number queues, even if not every queue is
> >   	 * currently configured. Since allocation of queues is in pairs,
> > -	 * use netdev->real_num_tx_queues * 2. The real_num_tx_queues is set
> > -	 * at device creation and never changes.
> > +	 * use netdev->num_tx_queues * 2. The num_tx_queues is set at
> > +	 * device creation and never changes.
> >   	 */
> >   
> >   	if (sset == ETH_SS_STATS)
> >   		return IAVF_STATS_LEN +
> > -			(IAVF_QUEUE_STATS_LEN * 2 *
> > -			 netdev->real_num_tx_queues);
> > +		       (IAVF_QUEUE_STATS_LEN * 2 * netdev->num_tx_queues);
> >   	else
> >   		return -EINVAL;
> >   }
> > @@ -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.
> 
> <rambling>
> zeroing inactive stats is bad behavior, not introduced by you of course, 
> but worth to fix (as a followup, not necessarily by you)

I agree.

> 
> unrelated to the prev paragraph,
> even if we remove explicit = 0 from the driver, ethtool userspace will
> still print (lots of) zeroes for "under-reported" stats, thanks to
> multi-syscall stats retrieval, that could be "fixed" in ethtool, but
> perhaps does not matter, as users use wrappers anyway
> </rambling>

The root cause of the OOB this time is that iavf_get_sset_count() uses
real_num_tx_queues for allocating buffers, and iavf_get_ethtool_stats()
uses num_active_queues for writing [1].

This may warrant more thought, but I was thinking that using
num_active_queues in all related functions would also be acceptable.

That's because, thanks to netdev_lock(), we can ensure num_active_queues
is unchanged within each ioctl call (ETHTOOL_GSSET_INFO,
ETHTOOL_GSTRINGS, ETHTOOL_GSTATS).
In other words, num_active_queues is effectively immutable for the
duration of a single ioctl, avoiding OOB.

[1] 
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()

  reply	other threads:[~2026-02-18  6:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-14 19:14 [PATCH v1 iwl-net] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats() Kohei Enju
2026-02-16 13:19 ` Simon Horman
2026-02-16 14:44   ` Kohei Enju
2026-02-16 15:17     ` Kohei Enju
2026-02-17 16:02     ` Simon Horman
2026-02-18  5:39 ` Przemek Kitszel
2026-02-18  6:31   ` Kohei Enju [this message]
2026-02-18  8:00 ` [Intel-wired-lan] " Paul Menzel
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=20260218063103.10265-1-kohei@enjuk.jp \
    --to=kohei@enjuk.jp \
    --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=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox