|SUCCESS| net/i40e: validate DDP segment header before use

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Thu Apr 30 01:11:52 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163344

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-29

git sha: 20260427154401.1813519-1-dish at amicon.ru
Author: Daniil Iskhakov <dish at amicon.ru>
Subject: [PATCH] net/i40e: validate DDP segment header before use

This patch fixes a potential NULL pointer dereference in
rte_pmd_i40e_get_ddp_info() by moving the validation of the i40e segment
header pointer earlier in the function, ensuring all code paths that use
it are protected.

> diff --git a/drivers/net/intel/i40e/rte_pmd_i40e.c b/drivers/net/intel/i40e/rte_pmd_i40e.c
> index 4fdef9464b..78b1f1f12d 100644
> --- a/drivers/net/intel/i40e/rte_pmd_i40e.c
> +++ b/drivers/net/intel/i40e/rte_pmd_i40e.c
> @@ -1878,6 +1878,11 @@ int rte_pmd_i40e_get_ddp_info(uint8_t *pkg_buff, uint32_t pkg_size,
>  		return I40E_SUCCESS;
>  	}
>  
> +	if (!i40e_seg_hdr) {
> +		PMD_DRV_LOG(ERR, "Failed to find i40e segment header");
> +		return -EINVAL;
> +	}
> +

The coding style guide states that checks against NULL should be
explicit. This check follows the correct pattern.

However, does the code ensure that all callers correctly handle the
-EINVAL return value? Some legacy code may expect I40E_SUCCESS or
positive error codes rather than negative errno values.

>  	/* get i40e segment header info */
>  	if (type == RTE_PMD_I40E_PKG_INFO_HEADER) {
>  		struct rte_pmd_i40e_profile_info *info =

[ ... ]

> @@ -1893,11 +1898,6 @@ int rte_pmd_i40e_get_ddp_info(uint8_t *pkg_buff, uint32_t pkg_size,
>  			return -EINVAL;
>  		}
>  
> -		if (!i40e_seg_hdr) {
> -			PMD_DRV_LOG(ERR, "Failed to find i40e segment header");
> -			return -EINVAL;
> -		}
> -
>  		memset(info, 0, sizeof(struct rte_pmd_i40e_profile_info));
>  		info->owner = RTE_PMD_I40E_DDP_OWNER_UNKNOWN;
>  		info->track_id =

The patch correctly moves the NULL check earlier in the function. Can you
verify that all switch/case branches between the early return at line
1878 and the usage of i40e_seg_hdr properly validate the pointer? Does
every code path that accesses i40e_seg_hdr after the new check location
now have protection?

Looking at the context provided, the function appears to have multiple
type checks. Are there any other types besides RTE_PMD_I40E_PKG_INFO_HEADER
that use i40e_seg_hdr and would benefit from this early validation?


More information about the test-report mailing list