From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org,
Avinash Dayanand <avinash.dayanand@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net 4/5] iavf: fix TC boundary check in iavf_handle_tclass
Date: Wed, 15 Apr 2026 14:46:42 +0100 [thread overview]
Message-ID: <20260415134642.GJ772670@horms.kernel.org> (raw)
In-Reply-To: <20260413073035.4082204-5-aleksandr.loktionov@intel.com>
On Mon, Apr 13, 2026 at 09:30:34AM +0200, Aleksandr Loktionov wrote:
> From: Avinash Dayanand <avinash.dayanand@intel.com>
>
> The condition `tc < adapter->num_tc` admits any tc value equal to or
> greater than num_tc, bypassing the destination-port validation and
> allowing traffic to be steered to a non-existent traffic class. Change
> the comparison to `tc > adapter->num_tc` to correctly reject
> out-of-range TC values.
>
> Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters")
> Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
I am a bit confused by this logic.
With this patch applied:
1) For tc <= adapter->num_tc, which I assume is valid TCs (other than 0,
in which case the function returns earlier), the filter destination port
is skipped.
But the failure path for that checks logs:
"Specify destination port to redirect to traffic class other than TC0\n"
This does not seem consistent.
2) For tc > adapter->num_tc, which I assume is invalid TCs,
the function will eventually assign fields of filter->f and succeed
if filter has a valid destination port.
This doesn't seem to be in keeping with the patch description.
3) The above two points aside, is there an out by 1 condition in
the condition tc > adapter->num_tc. It seems to imply
that tc == adapter->num_tc is a valid tc. But I suspect that
is not hte case.
In short, I'm wondering if the function should look something like this
(completely untested):
/**
* iavf_handle_tclass - Forward to a traffic class on the device
* @adapter: board private structure
* @tc: traffic class index on the device
* @filter: pointer to cloud filter structure
*/
static int iavf_handle_tclass(struct iavf_adapter *adapter, u32 tc,
struct iavf_cloud_filter *filter)
{
if (tc == 0)
return 0;
if (tc >= adapter->num_tc) {
// dev_err(...);
return -EINVAL;
}
if (!filter->f.data.tcp_spec.dst_port) {
dev_err(&adapter->pdev->dev,
"Specify destination port to redirect to traffic class other than TC0\n");
return -EINVAL;
}
/* redirect to a traffic class on the same device */
filter->f.action = VIRTCHNL_ACTION_TC_REDIRECT;
filter->f.action_meta = tc;
return 0;
}
> ---
> drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index ab5f5adc..5e4035b 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -4062,7 +4062,7 @@ static int iavf_handle_tclass(struct iavf_adapter *adapter, u32 tc,
> {
> if (tc == 0)
> return 0;
> - if (tc < adapter->num_tc) {
> + if (tc > adapter->num_tc) {
> if (!filter->f.data.tcp_spec.dst_port) {
> dev_err(&adapter->pdev->dev,
> "Specify destination port to redirect to traffic class other than TC0\n");
> --
> 2.52.0
>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org,
Avinash Dayanand <avinash.dayanand@intel.com>
Subject: Re: [PATCH iwl-net 4/5] iavf: fix TC boundary check in iavf_handle_tclass
Date: Wed, 15 Apr 2026 14:46:42 +0100 [thread overview]
Message-ID: <20260415134642.GJ772670@horms.kernel.org> (raw)
In-Reply-To: <20260413073035.4082204-5-aleksandr.loktionov@intel.com>
On Mon, Apr 13, 2026 at 09:30:34AM +0200, Aleksandr Loktionov wrote:
> From: Avinash Dayanand <avinash.dayanand@intel.com>
>
> The condition `tc < adapter->num_tc` admits any tc value equal to or
> greater than num_tc, bypassing the destination-port validation and
> allowing traffic to be steered to a non-existent traffic class. Change
> the comparison to `tc > adapter->num_tc` to correctly reject
> out-of-range TC values.
>
> Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters")
> Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
I am a bit confused by this logic.
With this patch applied:
1) For tc <= adapter->num_tc, which I assume is valid TCs (other than 0,
in which case the function returns earlier), the filter destination port
is skipped.
But the failure path for that checks logs:
"Specify destination port to redirect to traffic class other than TC0\n"
This does not seem consistent.
2) For tc > adapter->num_tc, which I assume is invalid TCs,
the function will eventually assign fields of filter->f and succeed
if filter has a valid destination port.
This doesn't seem to be in keeping with the patch description.
3) The above two points aside, is there an out by 1 condition in
the condition tc > adapter->num_tc. It seems to imply
that tc == adapter->num_tc is a valid tc. But I suspect that
is not hte case.
In short, I'm wondering if the function should look something like this
(completely untested):
/**
* iavf_handle_tclass - Forward to a traffic class on the device
* @adapter: board private structure
* @tc: traffic class index on the device
* @filter: pointer to cloud filter structure
*/
static int iavf_handle_tclass(struct iavf_adapter *adapter, u32 tc,
struct iavf_cloud_filter *filter)
{
if (tc == 0)
return 0;
if (tc >= adapter->num_tc) {
// dev_err(...);
return -EINVAL;
}
if (!filter->f.data.tcp_spec.dst_port) {
dev_err(&adapter->pdev->dev,
"Specify destination port to redirect to traffic class other than TC0\n");
return -EINVAL;
}
/* redirect to a traffic class on the same device */
filter->f.action = VIRTCHNL_ACTION_TC_REDIRECT;
filter->f.action_meta = tc;
return 0;
}
> ---
> drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index ab5f5adc..5e4035b 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -4062,7 +4062,7 @@ static int iavf_handle_tclass(struct iavf_adapter *adapter, u32 tc,
> {
> if (tc == 0)
> return 0;
> - if (tc < adapter->num_tc) {
> + if (tc > adapter->num_tc) {
> if (!filter->f.data.tcp_spec.dst_port) {
> dev_err(&adapter->pdev->dev,
> "Specify destination port to redirect to traffic class other than TC0\n");
> --
> 2.52.0
>
next prev parent reply other threads:[~2026-04-15 13:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 7:30 [Intel-wired-lan] [PATCH iwl-net 0/5] iavf: five correctness fixes Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 1/5] iavf: fix null pointer dereference in iavf_detect_recover_hung Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 12:48 ` [Intel-wired-lan] " Simon Horman
2026-04-15 12:48 ` Simon Horman
2026-05-11 8:25 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:25 ` Romanowski, Rafal
2026-05-11 11:39 ` Loktionov, Aleksandr
2026-05-11 11:39 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 2/5] iavf: fix error path in iavf_request_misc_irq Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-13 11:53 ` [Intel-wired-lan] " Przemek Kitszel
2026-04-13 11:53 ` Przemek Kitszel
2026-05-11 8:25 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:25 ` Romanowski, Rafal
2026-04-15 13:26 ` Simon Horman
2026-04-15 13:26 ` Simon Horman
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 3/5] iavf: prevent VSI corruption when ring params changed during reset Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:28 ` [Intel-wired-lan] " Simon Horman
2026-04-15 13:28 ` Simon Horman
2026-05-11 8:22 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:22 ` Romanowski, Rafal
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 4/5] iavf: fix TC boundary check in iavf_handle_tclass Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:46 ` Simon Horman [this message]
2026-04-15 13:46 ` Simon Horman
2026-05-11 8:22 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:22 ` Romanowski, Rafal
2026-05-11 11:32 ` Loktionov, Aleksandr
2026-05-11 11:32 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 5/5] iavf: return 0 when TC flower filter not found after qdisc teardown Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:53 ` [Intel-wired-lan] " Simon Horman
2026-04-15 13:53 ` Simon Horman
2026-05-11 8:23 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:23 ` Romanowski, Rafal
2026-05-11 8:21 ` [Intel-wired-lan] [PATCH iwl-net 0/5] iavf: five correctness fixes Romanowski, Rafal
2026-05-11 8:21 ` 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=20260415134642.GJ772670@horms.kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=avinash.dayanand@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@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.