|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