Re: [PATCH] net: bnxt: validate HWRM response length

[Pavan Chebbi]

On Mon, Nov 9, 2026 at 5:23 AM Noah Weinberger
<NoahWeinberger2003@xxxxxxxxx> wrote:
>
> Hello,
>
> Both HWRM completion paths compute the address of the valid bit
> from the firmware-provided response length without bounding it to the
> response area:
>
>     len = le16_to_cpu(READ_ONCE(ctx->resp->resp_len));
>     valid = ((u8 *)ctx->resp) + len - 1;
>     ...
>     if (*valid)   /* poll */
>     ...
>     *valid = 0;   /* zero for compatibility */
>
> The response area is the last PAGE_SIZE of the 2*PAGE_SIZE DMA
> allocation (BNXT_HWRM_RESP_RESERVED). Firmware that reports a
> resp_len above PAGE_SIZE (the field is u16, so up to 65535) makes the
> poll read and the *valid = 0 write land up to ~61 KB past the
> allocation, on every command. Lengths below the response header size
> are also accepted today.
>
> The patch rejects both cases before the pointer arithmetic, on the
> interrupt path and the polling path.

Its the FW's responsibility to properly write the response that fits
in the provided buffer and we must expect FW will do it.
IMO this patch is not necessary.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature