[DPDK/ethdev Bug 1881] tap: leaks in error paths

[DPDK/ethdev Bug 1881] tap: leaks in error paths

[bugzilla]

http://bugs.dpdk.org/show_bug.cgi?id=1881

            Bug ID: 1881
           Summary: tap: leaks in error paths
           Product: DPDK
           Version: 25.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

AI found these leaks

Error — Correctness Bugs:

    eth_dev_tap_create() error path leaks process_private (rte_eth_tap.c:2216)
— The error_exit label frees nlsk_fd, ka_fd, intr_handle, and releases the
port, but never calls free(dev->process_private). Every failed creation past
the malloc leaks that allocation.
    eth_dev_tap_create() leaks ethdev port on process_private malloc failure
(rte_eth_tap.c:2031) — Does return -1 directly instead of jumping to a cleanup
label, so the dev from rte_eth_vdev_allocate() is never released.
    Secondary process probe has 4 leaking error paths (rte_eth_tap.c:2509–2545)
— If rte_eal_primary_proc_alive() fails, process_private malloc fails,
tap_mp_attach_queues() fails, or rte_mp_action_register() fails, the function
returns -1 without freeing process_private or releasing eth_dev.
    tap_mp_attach_queues() leaks IPC reply buffer (rte_eth_tap.c:2425) — When
q_count != num_fds, returns -1 without calling free(reply). The
rte_mp_request_sync() API requires the caller to free replies.msgs.
    Use-after-free in tap_flow_create() (tap_flow.c:1284/1333) — flow is
inserted into pmd->flows at line 1284. If remote flow creation then fails, goto
fail calls tap_flow_free() which frees the memory but never calls
LIST_REMOVE(). The dangling pointer stays in the list and will be dereferenced
by tap_flow_flush().
    tap_flow_implicit_create() leaks remote_flow on EEXIST (tap_flow.c:1622) —
When the kernel returns EEXIST (rule already exists), the code jumps to success
returning 0, but the remote_flow allocated at line 1567 is neither freed nor
inserted into the list.

-- 
You are receiving this mail because:
You are the assignee for the bug.