|SUCCESS| net/octeontx: fix buffer overflow in device name formatting
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Wed Apr 8 15:49:34 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
Reviewing patch: net/octeontx: fix buffer overflow in device name formatting
git sha: f18b146c498d
Author: Sergei Iashin <yashin.sergey at gmail.com>
Subject: [PATCH] net/octeontx: fix buffer overflow in device name formatting
This patch replaces unsafe sprintf calls with snprintf to prevent
potential buffer overflows when formatting device names into fixed-size
buffers.
> 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 properly handle truncation? The function continues to use
octtx_name for rte_eth_dev_attach_secondary() and rte_eth_dev_allocate()
without checking if snprintf truncated the output. If the name is
truncated, could this lead to unexpected behavior or collisions with
other device names?
Should the code verify that snprintf's return value is less than
sizeof(octtx_name) and return an error if truncation occurs?
> if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> eth_dev = rte_eth_dev_attach_secondary(octtx_name);
> if (eth_dev == NULL)
[ ... ]
> @@ -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);
In octeontx_remove(), the format string is fixed ("eth_octeontx_%d"),
which appears safe since the maximum value of i is limited by
OCTEONTX_VDEV_DEFAULT_MAX_NR_PORT. However, the same truncation concern
applies: should the code verify the formatted string fits within the
buffer?
Also, does octeontx_remove() use a consistent naming scheme with
octeontx_create()? In octeontx_create(), the format is "%s_%d" where
%s comes from the 'name' parameter, but in octeontx_remove(), it's
hardcoded as "eth_octeontx_%d". Could this lead to a mismatch where
devices created with one naming scheme cannot be properly removed?
>
> eth_dev = rte_eth_dev_allocated(octtx_name);
> if (eth_dev == NULL)
More information about the test-report
mailing list