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: [email protected]
Reporter: [email protected]
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.
