Re: [PATCH net-next v2 2/7] net: mana: fix HWC RQ/SQ buffer size swap

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing hardware teardown on HWC establishment timeout leaves hardware with dangling DMA pointers, leading to Use-After-Free and Memory Corruption.
- [High] A malicious host/hypervisor can trigger an out-of-bounds read of kernel memory via a TOCTOU vulnerability in `mana_hwc_rx_event_handler`, leading to an information leak in Confidential VMs.
--

--- Patch [2]: [PATCH net-next v2 2/7] net: mana: fix HWC RQ/SQ buffer size swap ---
commit 1cb6d6f825cbbe1634272e9bfe16cb7adaa2c6b1
Author: Long Li <longli@microsoft.com>

net: mana: fix HWC RQ/SQ buffer size swap

The commit fixes a bug where mana_hwc_init_queues() sized the RQ and SQ
using the incorrect maximum message size variables. It swaps them to correct
the buffer sizes, stores max_resp_msg_size in the hardware channel context,
and uses it properly as the RX slot stride.

> diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> index 409e20caeccdc..3f011ebbe7b3e 100644
> --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> @@ -263,7 +263,7 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id,
>  
>  	/* Select the RX work request for virtual address and for reposting. */
>  	rq_base_addr = hwc_rxq->msg_buf->mem_info.dma_handle;
> -	rx_req_idx = (sge->address - rq_base_addr) / hwc->max_req_msg_size;
> +	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",

[Severity: High]
This is a pre-existing issue, but could this function be vulnerable to an
out-of-bounds read if the hypervisor provides a malicious
inline_oob_size_div4?

In mana_hwc_rx_event_handler(), the dma_oob pointer and its
inline_oob_size_div4 field are read from shared, unencrypted DMA memory:

    wqe = mana_gd_get_wqe_ptr(rq, rx_oob->wqe_offset / GDMA_WQE_BU_SIZE);
    dma_oob = (struct gdma_wqe *)wqe;
    sge = (struct gdma_sge *)(wqe + 8 + dma_oob->inline_oob_size_div4 * 4);

If a malicious hypervisor sends a CQE pointing to the last WQE slot in
the ring buffer and sets the 3-bit inline_oob_size_div4 field to 7, the
calculated sge pointer would point 4 bytes past the end of the 32-byte
WQE buffer allocation.

The driver then reads sge->address (an 8-byte out-of-bounds read) to
compute rx_req_idx. Since this value is derived from out-of-bounds
memory, it will likely exceed num_reqs and be logged to the kernel ring
buffer.

Could an untrusted hypervisor use this paravirtualized serial console log
to reverse the math and recover leaked encrypted guest memory plaintext
in a Confidential VM setup?

[ ... ]

> @@ -733,14 +733,14 @@ static int mana_hwc_init_queues(struct hw_channel_context *hwc, u16 q_depth,
>  		goto out;
>  	}
>  
> -	err = mana_hwc_create_wq(hwc, GDMA_RQ, q_depth, max_req_msg_size,
> +	err = mana_hwc_create_wq(hwc, GDMA_RQ, q_depth, max_resp_msg_size,
>  				 hwc->cq, &hwc->rxq);

[Severity: High]
This isn't a bug introduced by this patch, but is there a missing hardware
teardown when channel establishment times out?

In mana_hwc_establish_channel(), mana_smc_setup_hwc() hands the DMA
addresses of the queues to the hardware. If the driver then times out
waiting for the hwc_init_eqe_comp completion, it returns -ETIMEDOUT.

On the error path, this leads to mana_hwc_destroy_channel(), where the
teardown is gated by the number of completion queues:

    if (gc->max_num_cqs > 0)
        mana_smc_teardown_hwc(&gc->shm_channel, false);

Because the initialization event was never processed due to the timeout,
gc->max_num_cqs is still 0, causing the teardown to be skipped. The
driver then immediately frees the DMA queue memory.

If the hardware later wakes up and processes the setup request, could it
write to the freed DMA memory, resulting in memory corruption?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721234339.1476932-1-longli@microsoft.com?part=2