|SUCCESS| net/octeontx: fix buffer overflow in device name formatting

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Wed Apr 8 14:40:33 CEST 2026


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

_AI Code Review_

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

git sha: f18b146c498d ("net/octeontx: create ethdev ports")
Author: Sergei Iashin <yashin.sergey at gmail.com>
Subject: [PATCH] net/octeontx: fix buffer overflow in device name formatting

This patch replaces sprintf with snprintf when formatting device names
into a fixed-size buffer to prevent potential stack buffer overflows when
user-provided device names are long.

> diff --git a/drivers/net/octeontx/octeontx_ethdev.c b/drivers/net/octeontx/octeontx_ethdev.c
> index 21e3e56901..e4dca30d9d 100644
> --- a/drivers/net/octeontx/octeontx_ethdev.c
> +++ b/drivers/net/octeontx/octeontx_ethdev.c
> @@ -1555,7 +1555,7 @@ octeontx_create(struct rte_vdev_device *dev, int port, uint8_t evdev,
>  
>  	PMD_INIT_FUNC_TRACE();
>  
> -	sprintf(octtx_name, "%s_%d", name, port);
> +	snprintf(octtx_name, sizeof(octtx_name), "%s_%d", name, port);

Does this code check for truncation after the snprintf call? The function
continues to use octtx_name even if the name was truncated, which could
lead to using a partial device name in rte_eth_dev_attach_secondary() and
rte_eth_dev_allocate().

[ ... ]

> @@ -1711,7 +1711,7 @@ octeontx_remove(struct rte_vdev_device *dev)
>  		return -EINVAL;
>  
>  	for (i = 0; i < OCTEONTX_VDEV_DEFAULT_MAX_NR_PORT; i++) {
> -		sprintf(octtx_name, "eth_octeontx_%d", i);
> +		snprintf(octtx_name, sizeof(octtx_name), "eth_octeontx_%d", i);

Can this snprintf call actually truncate the string? The format
"eth_octeontx_%d" with a reasonable port number should fit within 32
bytes. However, if OCTEONTX_VDEV_DEFAULT_MAX_NR_PORT allows very large
values of i, could this theoretically overflow? What is the maximum value
of i here?

In octeontx_create(), does the code handle the case where name itself is
already very long (close to RTE_DEV_NAME_MAX_LEN)? If name is 60 bytes and
we append "_%d", would the snprintf truncate silently, potentially causing
name collisions or lookup failures later?


More information about the test-report mailing list