All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wei Hu" <weh@linux.microsoft.com>
Cc: linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net-next v7 3/4] net: mana: support concurrent HWC requests
Date: Wed, 14 Oct 2026 08:06:24 +0000	[thread overview]
Message-ID: <sashiko-outbox-170991@kernel.org> (raw)
In-Reply-To: <08f833983788be99fc73b856dd4822826b5876f7.1791561995.git.weh@linux.microsoft.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: mana: out-of-bounds read on unvalidated hardware msg_id
--

commit 9775f43816d83151fa521309768c62ad04b477da
Author: Long Li <longli@microsoft.com>

net: mana: support concurrent HWC requests

This commit replaces the depth-one timeout latch with per-slot sender and
response ownership. It synchronizes timeout updates, implements runtime
teardown logic, and splits HWC request paths into structured helpers to
support concurrent hardware channel requests.

Link: https://lore.kernel.org/r/20260908035201.402424-4-longli@microsoft.com
Link: https://lore.kernel.org/r/20260914175044.2a26bb46@kernel.org

> diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> index 89b6e30863dae..9fdd84ccba653 100644
> --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c

[ ... ]

> @@ -97,40 +162,54 @@ static void mana_hwc_handle_resp(struct hw_channel_context *hwc, u32 resp_len,
>  				 struct hwc_work_request *rx_req, u16 msg_id)
>  {
>  	const struct gdma_resp_hdr *resp_msg = rx_req->buf_va;
> +	struct gdma_resource *r = &hwc->inflight_msg_res;
>  	struct hwc_caller_ctx *ctx;
> +	bool release;
>  	int err;
>  
> -	if (!test_bit(msg_id, hwc->inflight_msg_res.map)) {
> +	spin_lock(&r->lock);
> +	if (!test_bit(msg_id, r->map)) {
> +		spin_unlock(&r->lock);
>  		dev_err(hwc->dev, "hwc_rx: invalid msg_id = %u\n", msg_id);
>  		mana_hwc_post_rx_wqe(hwc->rxq, rx_req);
>  		return;
>  	}
>  
>  	ctx = hwc->caller_ctx + msg_id;

[Severity: High]
Can this result in an out-of-bounds memory access if the hardware returns an
invalid msg_id?

The msg_id value originates from the hardware completion structure. In
mana_hwc_handle_resp(), it is used directly in test_bit(msg_id, r->map) and
as an array offset for hwc->caller_ctx without any bounds verification.

If the hardware provides a malformed msg_id (e.g., larger than r->size),
test_bit() will perform an out-of-bounds read, and the array indexing will
result in out-of-bounds pointer arithmetic. This can subsequently lead to
memory corruption when the code acquires ctx->lock and copies data into
ctx->output_buf.

Should there be a bounds check against r->size or hwc->num_inflight_msg
before msg_id is used here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791561995.git.weh@linux.microsoft.com?part=3

  reply	other threads:[~2026-10-14  8:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  8:05 [PATCH net-next v7 0/4] net: mana: concurrent HWC requests and dynamic queue depth Wei Hu
2026-10-13  8:05 ` [PATCH net-next v7 1/4] net: mana: prepare HWC ownership for safe reinitialization Wei Hu
2026-10-14  8:06   ` sashiko-bot
2026-10-13  8:05 ` [PATCH net-next v7 2/4] net: mana: give each HWC message slot its own completion state Wei Hu
2026-10-14  8:06   ` sashiko-bot
2026-10-13  8:05 ` [PATCH net-next v7 3/4] net: mana: support concurrent HWC requests Wei Hu
2026-10-14  8:06   ` sashiko-bot [this message]
2026-10-13  8:05 ` [PATCH net-next v7 4/4] net: mana: add dynamic HWC queue depth with reinit path Wei Hu
2026-10-14  8:06   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-10-14  8:15 [PATCH net-next v7 3/4] net: mana: support concurrent HWC requests netdev-bot+sashiko

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=sashiko-outbox-170991@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=weh@linux.microsoft.com \
    /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.