Re: [PATCH net v3] i40e: limit the DDP profile count returned by the firmware

[Simon Horman]

On Tue, Sep 22, 2026 at 05:11:23PM +0800, Linkui Xiao wrote:
> From: Linkui Xiao <xiaolinkui@xxxxxxxxxx>
> 
> i40e_aq_get_ddp_list() writes into a I40E_PROFILE_LIST_SIZE buffer, which
> is sized for I40E_MAX_PROFILE_NUM (16) i40e_profile_info entries plus the
> 4 byte p_count header. i40e_ddp_does_profile_exist() and
> i40e_ddp_does_profile_overlap() then loop over profile_list->p_count
> without bounding it, so a firmware reporting more than 16 profiles makes
> both helpers walk past the end of the on-stack buff[] and compare against
> whatever happens to follow it on the stack.
> 
> The same buffer is handed to the firmware as an indirect admin queue
> buffer, and the admin queue code copies all of it into the DMA bounce
> buffer before submitting the command, so its uninitialized contents were
> visible to the device as well.
> 
> Zero initialize buff[] and reject the list when the firmware reports more
> profiles than the buffer can hold, instead of answering from a list that
> was only partially read. Both helpers already report errors to
> i40e_ddp_load(), which aborts the operation.
> 
> Fixes: cdc594e00370 ("i40e: Implement DDP support in i40e driver")
> Signed-off-by: Linkui Xiao <xiaolinkui@xxxxxxxxxx>
> ---
> Changes in v3:
> - Zero initialize buff[] in both helpers: the whole buffer is copied into
>   the admin queue DMA bounce buffer and copied back afterwards, so its
>   contents were exposed to the device, and entries the firmware never
>   wrote were compared against. (Sashiko AI review)
> - Reject the list when the firmware reports more profiles than buff[] can
>   hold, instead of silently clamping the scan and then answering from a
>   list that was only partially read. (Sashiko AI review)
> - Dropped the Reviewed-by tag, as the code changed after the review.

Thanks for the updates.

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>