From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D895D3ACEE0; Wed, 15 Jul 2026 03:30:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784086220; cv=none; b=BOWaViRIfLO2gTewG/NUrsWSTwU6JTDgmQB7tFBozimS8pHti3yBb6IF89urYiTsXTmVd3BYpjNcpdY2LM4fZ5TI8gdXgPlPQiCnNqu1RPyiyJOWNqvKOlzkzSavZNmvHvtqVhqhK0exlCj97wWxKXsW6wb6AfxCorEexPmdoqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784086220; c=relaxed/simple; bh=VsixF+qnTTCLETMM5CI39ot8RDAO0bs0NG4gHjgFEoQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=elK7Yn4lRSeALXJnNxeswXtKS1XQIMQdsCEeCICqtidoYExU/BZNLAC69P2vmWSCFvEZI2hUS3iyrW5LkZzp98/kObEAxndWiBoa78yI3Eihdi40+jl6dhBQ7wLEjCRU8wa0pV9d5d93xjEev/tvrfMwZAuGUiV9v1mya14lvQ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: by linux.microsoft.com (Postfix, from userid 1202) id 7223420B7168; Tue, 14 Jul 2026 20:30:00 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7223420B7168 From: Long Li To: Long Li , Konstantin Taranov , Jakub Kicinski , "David S . Miller" , Paolo Abeni , Eric Dumazet , Andrew Lunn , Jason Gunthorpe , Leon Romanovsky , Haiyang Zhang , "K . Y . Srinivasan" , Wei Liu , Dexuan Cui , shradhagupta@linux.microsoft.com, Simon Horman Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next 4/7] net: mana: validate hardware-supplied values in the HWC RX path Date: Tue, 14 Jul 2026 20:29:38 -0700 Message-ID: <20260715032942.3945317-5-longli@microsoft.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260715032942.3945317-1-longli@microsoft.com> References: <20260715032942.3945317-1-longli@microsoft.com> Precedence: bulk X-Mailing-List: linux-rdma@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mana_hwc_rx_event_handler() and mana_hwc_handle_resp() consumed lengths and indices taken straight from device DMA without validation. A buggy firmware or a malicious host (in a confidential VM, where the DMA buffer is shared) could drive a wrong or reused in-flight request to completion or index out of bounds. Validate before use: - match the SGE address against the address the driver posted for that slot, not just an in-range index -- an in-range but wrong SGE would otherwise truncate onto a neighbouring slot and read a stale response; - require the response to cover a full gdma_resp_hdr before reading hwc_msg_id, so a short response cannot complete a slot with stale bytes left by the buffer's previous occupant; - bounds-check hwc_msg_id in mana_hwc_handle_resp() before indexing the inflight bitmap and caller_ctx; - reject a resp_len larger than the RX buffer. Repost the RX WQE on every validation early-return so a rejected response does not permanently shrink the posted RQ depth. The one path that cannot identify the slot (SGE mismatch) intentionally leaks a single WQE rather than risk reposting the wrong one. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Long Li --- .../net/ethernet/microsoft/mana/hw_channel.c | 58 +++++++++++++++++-- 1 file changed, 54 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c index 2239fdeda57c..68236727aee8 100644 --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c @@ -83,6 +83,17 @@ static void mana_hwc_handle_resp(struct hw_channel_context *hwc, u32 resp_len, struct hwc_caller_ctx *ctx; int err; + /* Validate msg_id is in range before using it to index bitmap + * and caller_ctx array. Malicious firmware could send + * out-of-range msg_id causing out-of-bounds access. + */ + if (msg_id >= hwc->num_inflight_msg) { + dev_err(hwc->dev, "hwc_rx: msg_id %u >= max %u\n", + msg_id, hwc->num_inflight_msg); + mana_hwc_post_rx_wqe(hwc->rxq, rx_req); + return; + } + if (!test_bit(msg_id, hwc->inflight_msg_res.map)) { dev_err(hwc->dev, "hwc_rx: invalid msg_id = %u\n", msg_id); mana_hwc_post_rx_wqe(hwc->rxq, rx_req); @@ -90,6 +101,18 @@ static void mana_hwc_handle_resp(struct hw_channel_context *hwc, u32 resp_len, } ctx = hwc->caller_ctx + msg_id; + + /* Reject responses larger than the RX DMA buffer — the SGE + * limits what hardware can DMA, so an oversized resp_len + * indicates a firmware bug. Fail rather than silently + * truncating. + */ + if (resp_len > rx_req->buf_len) { + dev_err(hwc->dev, "HWC RX: resp_len %u > buf_len %u\n", + resp_len, rx_req->buf_len); + resp_len = 0; + } + err = mana_hwc_verify_resp_msg(ctx, resp_msg, resp_len); if (err) goto out; @@ -261,19 +284,45 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id, sge = (struct gdma_sge *)(wqe + 8 + dma_oob->inline_oob_size_div4 * 4); - /* Select the RX work request for virtual address and for reposting. */ + /* Recover the originating RX slot from the SGE address. Of the three + * terms here only sge->address lives in device-accessible RQ memory; + * rq_base_addr and max_resp_msg_size are driver-private constants. An + * in-range but wrong/unaligned SGE (corrupted WQE, or a malicious host + * in a CVM) would otherwise truncate onto a neighbouring slot, letting + * us read a stale response that could complete the wrong, reused + * in-flight request. Require the index to be in range AND the address + * to exactly match the value the driver posted for that slot. + */ rq_base_addr = hwc_rxq->msg_buf->mem_info.dma_handle; rx_req_idx = (sge->address - rq_base_addr) / hwc->max_resp_msg_size; - if (rx_req_idx >= hwc_rxq->msg_buf->num_reqs) { - dev_err(hwc->dev, "HWC RX: wrong rx_req_idx=%llu, num_reqs=%u\n", - rx_req_idx, hwc_rxq->msg_buf->num_reqs); + if (rx_req_idx >= hwc_rxq->queue_depth || + sge->address != (u64)hwc_rxq->msg_buf->reqs[rx_req_idx].buf_sge_addr) { + /* Cannot trust which WQE this is, so we cannot safely repost + * it; leak one RX WQE and bail. This permanently leaks one + * RX WQE but indicates a corrupted SGE from hardware (or host + * tampering), which is an unrecoverable device error. + */ + dev_err(hwc->dev, "HWC RX: invalid SGE address %llx (idx=%llu)\n", + sge->address, rx_req_idx); return; } rx_req = &hwc_rxq->msg_buf->reqs[rx_req_idx]; resp = (struct gdma_resp_hdr *)rx_req->buf_va; + /* Validate resp_len covers the response header before reading + * hwc_msg_id. A short response leaves stale data from the + * previous buffer occupant, which could match a live slot and + * complete the wrong request. + */ + if (rx_oob->tx_oob_data_size < sizeof(*resp)) { + dev_err(hwc->dev, "HWC RX: short resp_len=%u\n", + rx_oob->tx_oob_data_size); + mana_hwc_post_rx_wqe(hwc_rxq, rx_req); + return; + } + /* Read msg_id once from DMA buffer to prevent TOCTOU: * DMA memory is shared/unencrypted in CVMs - host can * modify it between reads. @@ -281,6 +330,7 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id, msg_id = READ_ONCE(resp->response.hwc_msg_id); if (msg_id >= hwc->num_inflight_msg) { dev_err(hwc->dev, "HWC RX: wrong msg_id=%u\n", msg_id); + mana_hwc_post_rx_wqe(hwc_rxq, rx_req); return; } -- 2.43.0