memif: advertises incorrect queue pairs

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.