From: Simon Horman <horms@kernel.org>
To: Pengpeng Hou <pengpeng@iscas.ac.cn>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] qed: fcoe: limit command queue array fill to the ramrod array size
Date: Thu, 26 Mar 2026 17:46:23 +0000 [thread overview]
Message-ID: <20260326174623.GS111839@horms.kernel.org> (raw)
In-Reply-To: <20260324105647.92763-1-pengpeng@iscas.ac.cn>
On Tue, Mar 24, 2026 at 06:56:47PM +0800, Pengpeng Hou wrote:
> qed_sp_fcoe_func_start() validates fcoe_pf_params->num_cqs against the
> number of command queues exposed by the hardware resource table, but it
> then uses that count to fill q_params.cq_cmdq_sb_num_arr[] in the FCoE
> init ramrod. That array is fixed at SCSI_MAX_NUM_OF_CMDQS entries.
>
> The in-tree qedf caller derives num_cqs from the device's reported
> num_cqs and the online CPU count, so current-tree callers can request
> more queues than fit in the fixed ramrod array on sufficiently large
> systems even though the existing hardware-resource check passes.
>
> Reject queue counts that exceed the command queue array capacity before
> filling the ramrod.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_fcoe.c b/drivers/net/ethernet/qlogic/qed/qed_fcoe.c
> index 2ae3639d6cf7..5fbf78f6adca 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_fcoe.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_fcoe.c
> @@ -126,6 +126,15 @@ qed_sp_fcoe_func_start(struct qed_hwfn *p_hwfn,
> goto err;
> }
>
Hi,
The code immediately above checks fcoe_pf_params->num_cqs
against p_hwfn->hw_info.feat_num[QED_FCOE_CQ], which I assume
is derived from hardware.
Is that sufficient to avoid the OOB access you describe?
> + if (fcoe_pf_params->num_cqs > ARRAY_SIZE(p_data->q_params.cq_cmdq_sb_num_arr)) {
> + DP_ERR(p_hwfn,
> + "Cannot fit %u queues in %zu command queue slots. Aborting function start\n",
> + fcoe_pf_params->num_cqs,
> + ARRAY_SIZE(p_data->q_params.cq_cmdq_sb_num_arr));
> + rc = -EINVAL;
> + goto err;
> + }
> +
> p_data->mtu = cpu_to_le16(fcoe_pf_params->mtu);
> tmp = cpu_to_le16(fcoe_pf_params->sq_num_pbl_pages);
> p_data->sq_num_pages_in_pbl = tmp;
> --
> 2.50.1 (Apple Git-155)
>
next prev parent reply other threads:[~2026-03-26 17:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 10:56 [PATCH] qed: fcoe: limit command queue array fill to the ramrod array size Pengpeng Hou
2026-03-26 17:46 ` Simon Horman [this message]
2026-03-27 0:49 ` Pengpeng Hou
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=20260326174623.GS111839@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pengpeng@iscas.ac.cn \
/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.