From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: 'Simon Horman' <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
Date: Mon, 13 Apr 2026 15:03:07 +0100 [thread overview]
Message-ID: <20260413140307.715409-1-horms@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-7-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
This commit fixes two bugs in ixgbe_validate_rtr() by masking the
traffic-class field properly before assigning it to a u8, and correctly
shifting the mask for clearing out-of-bounds entries.
Cc: stable@vger.kernel.org
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 5ff462a848feb..8ebf717ce4017 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9782,11 +9782,12 @@ static void ixgbe_validate_rtr(struct ixgbe_adapter *adapter, u8 tc)
> rsave = reg;
>
> for (i = 0; i < MAX_TRAFFIC_CLASS; i++) {
> - u8 up2tc = reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT);
> + u8 up2tc = (reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT)) &
> + IXGBE_RTRUP2TC_UP_MASK;
>
> /* If up2tc is out of bounds default to zero */
> if (up2tc > tc)
This wasn't introduced by this patch, but is there a pre-existing off-by-one
error in this bounds check?
If tc represents the number of enabled traffic classes (e.g., 4), the valid TC
indices would be 0 through tc - 1. If up2tc equals tc, it would be out of
bounds, but the condition up2tc > tc will evaluate to false and the invalid
mapping won't be cleared.
Could this allow an invalid UP-to-TC mapping to persist in the hardware
register, potentially causing received packets to be mis-steered to an
uninitialized or non-existent traffic class queue?
Should the condition be corrected to ensure up2tc is strictly less than tc
when tc > 0?
> - reg &= ~(0x7 << IXGBE_RTRUP2TC_UP_SHIFT);
> + reg &= ~(IXGBE_RTRUP2TC_UP_MASK << (i * IXGBE_RTRUP2TC_UP_SHIFT));
> }
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: 'Simon Horman' <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
Date: Mon, 13 Apr 2026 15:03:07 +0100 [thread overview]
Message-ID: <20260413140307.715409-1-horms@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-7-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
This commit fixes two bugs in ixgbe_validate_rtr() by masking the
traffic-class field properly before assigning it to a u8, and correctly
shifting the mask for clearing out-of-bounds entries.
Cc: stable@vger.kernel.org
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 5ff462a848feb..8ebf717ce4017 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9782,11 +9782,12 @@ static void ixgbe_validate_rtr(struct ixgbe_adapter *adapter, u8 tc)
> rsave = reg;
>
> for (i = 0; i < MAX_TRAFFIC_CLASS; i++) {
> - u8 up2tc = reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT);
> + u8 up2tc = (reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT)) &
> + IXGBE_RTRUP2TC_UP_MASK;
>
> /* If up2tc is out of bounds default to zero */
> if (up2tc > tc)
This wasn't introduced by this patch, but is there a pre-existing off-by-one
error in this bounds check?
If tc represents the number of enabled traffic classes (e.g., 4), the valid TC
indices would be 0 through tc - 1. If up2tc equals tc, it would be out of
bounds, but the condition up2tc > tc will evaluate to false and the invalid
mapping won't be cleared.
Could this allow an invalid UP-to-TC mapping to persist in the hardware
register, potentially causing received packets to be mis-steered to an
uninitialized or non-existent traffic class queue?
Should the condition be corrected to ensure up2tc is strictly less than tc
when tc > 0?
> - reg &= ~(0x7 << IXGBE_RTRUP2TC_UP_SHIFT);
> + reg &= ~(IXGBE_RTRUP2TC_UP_MASK << (i * IXGBE_RTRUP2TC_UP_SHIFT));
> }
next prev parent reply other threads:[~2026-04-13 14:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 13:11 [Intel-wired-lan] [PATCH iwl-net v2 0/6] ixgbe: six bug fixes Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 1/6] ixgbe: fix SWFW semaphore timeout for X550 family Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:52 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:52 ` Simon Horman
2026-04-14 0:56 ` [Intel-wired-lan] " Jacob Keller
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 2/6] ixgbe: add bounds check for debugfs register access Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:30 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:30 ` Simon Horman
2026-04-14 1:00 ` [Intel-wired-lan] " Jacob Keller
2026-04-14 17:16 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 3/6] ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:51 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:51 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 4/6] ixgbe: fix cls_u32 nexthdr path returning success when no entry installed Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:54 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:54 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 5/6] ixgbe: fix ITR value overflow in adaptive interrupt throttling Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 13:39 ` [Intel-wired-lan] " Simon Horman
2026-04-13 13:39 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr() Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 13:43 ` [Intel-wired-lan] " Simon Horman
2026-04-13 13:43 ` Simon Horman
2026-04-13 14:02 ` [Intel-wired-lan] " Simon Horman
2026-04-13 14:02 ` Simon Horman
2026-04-13 14:03 ` Simon Horman [this message]
2026-04-13 14:03 ` Simon Horman
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=20260413140307.715409-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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.