From: Simon Horman <horms@kernel.org>
To: Junrui Luo <moonafterrain@outlook.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Mitch Williams <mitch.a.williams@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Yuhao Jiang <danisjiang@gmail.com>,
stable@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH net v2] iavf: validate num_vsis in VIRTCHNL_OP_GET_VF_RESOURCES response
Date: Mon, 18 May 2026 19:56:11 +0100 [thread overview]
Message-ID: <20260518185611.GF98116@horms.kernel.org> (raw)
In-Reply-To: <SYBPR01MB788139F8F31129E4B64E66D4AF072@SYBPR01MB7881.ausprd01.prod.outlook.com>
On Thu, May 14, 2026 at 02:55:04PM +0800, Junrui Luo wrote:
> The VF allocates a fixed-size buffer for IAVF_MAX_VF_VSI (3) VSI
> entries when processing a VIRTCHNL_OP_GET_VF_RESOURCES response from
> the PF. However, num_vsis from the PF response is used unchecked as
> the loop bound when iterating over vsi_res[] in multiple functions.
>
> A PF sending num_vsis greater than IAVF_MAX_VF_VSI, or the received
> message is shorter than num_vsis claims leads to out-of-bounds accesses
> on the vsi_res[] array.
>
> Clamp num_vsis based on the actual bytes copied from the PF response.
>
> Fixes: 5eae00c57f5e ("i40evf: main driver core")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> Changes in v2:
> - Clamp num_vsis based on actual received message length instead of
> IAVF_MAX_VF_VSI suggested by Przemek
> - Link to v1: https://lore.kernel.org/r/SYBPR01MB7881AF11C45AEDC0D4CA89C1AF062@SYBPR01MB7881.ausprd01.prod.outlook.com
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI-generated review of this patchset available on sashiko.dev.
However, I believe that the issues raised there can be considered in
the context of possible follow-up. I do not believe they should block
progress of this patch.
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Junrui Luo <moonafterrain@outlook.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Mitch Williams <mitch.a.williams@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Yuhao Jiang <danisjiang@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH net v2] iavf: validate num_vsis in VIRTCHNL_OP_GET_VF_RESOURCES response
Date: Mon, 18 May 2026 19:56:11 +0100 [thread overview]
Message-ID: <20260518185611.GF98116@horms.kernel.org> (raw)
In-Reply-To: <SYBPR01MB788139F8F31129E4B64E66D4AF072@SYBPR01MB7881.ausprd01.prod.outlook.com>
On Thu, May 14, 2026 at 02:55:04PM +0800, Junrui Luo wrote:
> The VF allocates a fixed-size buffer for IAVF_MAX_VF_VSI (3) VSI
> entries when processing a VIRTCHNL_OP_GET_VF_RESOURCES response from
> the PF. However, num_vsis from the PF response is used unchecked as
> the loop bound when iterating over vsi_res[] in multiple functions.
>
> A PF sending num_vsis greater than IAVF_MAX_VF_VSI, or the received
> message is shorter than num_vsis claims leads to out-of-bounds accesses
> on the vsi_res[] array.
>
> Clamp num_vsis based on the actual bytes copied from the PF response.
>
> Fixes: 5eae00c57f5e ("i40evf: main driver core")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> Changes in v2:
> - Clamp num_vsis based on actual received message length instead of
> IAVF_MAX_VF_VSI suggested by Przemek
> - Link to v1: https://lore.kernel.org/r/SYBPR01MB7881AF11C45AEDC0D4CA89C1AF062@SYBPR01MB7881.ausprd01.prod.outlook.com
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI-generated review of this patchset available on sashiko.dev.
However, I believe that the issues raised there can be considered in
the context of possible follow-up. I do not believe they should block
progress of this patch.
next prev parent reply other threads:[~2026-05-18 18:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 8:51 [PATCH net] iavf: validate num_vsis in VIRTCHNL_OP_GET_VF_RESOURCES response Junrui Luo
2026-05-13 8:51 ` [Intel-wired-lan] " Junrui Luo
2026-05-13 11:10 ` Przemek Kitszel
2026-05-13 11:10 ` [Intel-wired-lan] " Przemek Kitszel
2026-05-14 6:55 ` [Intel-wired-lan] [PATCH net v2] " Junrui Luo
2026-05-14 6:55 ` Junrui Luo
2026-05-14 9:07 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-05-14 9:07 ` Loktionov, Aleksandr
2026-05-18 18:56 ` Simon Horman [this message]
2026-05-18 18:56 ` 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=20260518185611.GF98116@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=danisjiang@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregory.v.rose@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mitch.a.williams@intel.com \
--cc=moonafterrain@outlook.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--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.