https://bugs.dpdk.org/show_bug.cgi?id=2014
Bug ID: 2014
Summary: memif: advertises incorrect queue pairs
Product: DPDK
Version: 26.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Found while doing AI assisted review of memif.
memif_msg_enq_hello() in drivers/net/memif/memif_socket.c sends
h->max_c2s_ring = ETH_MEMIF_MAX_NUM_Q_PAIRS;
h->max_s2c_ring = ETH_MEMIF_MAX_NUM_Q_PAIRS;
that is, the driver-wide maximum (255), rather than the number of rings
the device is actually configured with, pmd->cfg.num_c2s_rings and
pmd->cfg.num_s2c_rings.
A conforming client negotiates its ring count as
RTE_MIN(h->max_c2s_ring + 1, its own count), so it can legitimately end
up sending more ADD_RING messages than the server has queues for. The
existing check in memif_msg_receive_add_ring(),
if (ar->index >= pmd->cfg.num_c2s_rings)
then rejects the ring and disconnects the peer. The client did nothing
wrong; the server told it the wrong limit.
Fix: advertise the device's configured ring counts in the hello.
This is a functional bug, not a security one, but it becomes much more
visible as soon as the server starts validating client requests
strictly, so it is worth fixing alongside that work rather than after
it.
--
You are receiving this mail because:
You are the assignee for the bug.
