[PATCH] net/tap: fix close for partially configured port

[Stephen Hemminger]

On Thu, 26 Mar 2026 13:46:11 +0100
David Marchand <david.marchand at redhat.com> wrote:

> In case no rxq has been set up (like when starting testpmd with no mempool
> drivers), a crash happens in tap_dev_close:
> 
> Thread 1 "dpdk-testpmd" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7fad68b in tap_dev_close (dev=dev at entry=0x4c4a80
> 	<rte_eth_devices at INTERNAL>) at ../drivers/net/tap/rte_eth_tap.c:1111
> 1111			struct rx_queue *rxq = dev->data->rx_queues[i];
> 
> (gdb) p dev->data->rx_queues
> $4 = (void **) 0x0
> 
> Fixes: 23e2387b49a1 ("net/tap: allocate queue structures dynamically")
> 
> Signed-off-by: David Marchand <david.marchand at redhat.com>
> ---

It looked ok, but then the AI review spotted some stuff...


Two issues:

The txq variable is declared as struct rx_queue * but should be
struct tx_queue *. Works by accident since it comes from a void *
array and is only NULL-tested and passed to rte_free(), but the
type is wrong.

Pre-existing: the loop runs to RTE_PMD_TAP_MAX_QUEUES but the
rx_queues/tx_queues arrays are allocated with nb_rx_queues /
nb_tx_queues entries by ethdev. If dev_configure() was called
with fewer queues, the arrays are non-NULL but the access is
out-of-bounds. Since these lines are being reworked anyway, worth
adding a bounds check against nb_rx_queues/nb_tx_queues. The
tap_queue_close() call is fine -- process_private fds are sized
to RTE_PMD_TAP_MAX_QUEUES.

Also missing Cc: stable at dpdk.org for a crash fix.