All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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.