From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/eventdev Bug 2034] eventdev: dangling pointer on error path in rxa_sw_add()
Date: Thu, 10 Sep 2026 12:29:58 +0000 [thread overview]
Message-ID: <bug-2034-3@https.bugs.dpdk.org/> (raw)
https://bugs.dpdk.org/show_bug.cgi?id=2034
Bug ID: 2034
Summary: eventdev: dangling pointer on error path in
rxa_sw_add()
Product: DPDK
Version: 26.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: eventdev
Assignee: dev@dpdk.org
Reporter: yangshuaisong@h-partners.com
Target Milestone: ---
[Overview]
A code quality / dangling pointer issue was identified via static analysis in
the eventdev library. In `rxa_sw_add()`, a newly allocated buffer is attached
to a structure pointer before all resource allocations succeed. If a subsequent
allocation fails, the buffer memory is freed, but the structure pointer is not
cleared, leaving a dangling pointer (`queue_info->event_buf`).
[Location]
- File: lib/eventdev/rte_event_eth_rx_adapter.c
- Function: `rxa_sw_add()`
- Lines: 2175, 2181-2187 (or adjacent lines depending on version)
[Environment & Build]
- DPDK Version: [26.03]
- OS / Kernel: Generic
- Tool: Identified via static code analysis / code audit.
[Vulnerability Logic & Analysis]
Looking at the implementation of `rxa_sw_add()`:
1. At line 2175, the newly allocated event buffer `new_rx_buf` is assigned to
the queue information structure:
```c
queue_info->event_buf = new_rx_buf;
```
2. Subsequently, at lines 2181-2187, the function attempts to allocate memory
for `stats`. If `stats == NULL` (allocation failure), it rolls back by freeing
the sub-elements and the buffer itself:
```c
if (stats == NULL) {
rte_free(new_rx_buf->events);
rte_free(new_rx_buf);
RTE_EDEV_LOG_ERR(...);
return -ENOMEM;
}
```
3. However, during this error path and cleanup, `queue_info->event_buf` is
never reset to `NULL`. It retains the memory address of `new_rx_buf` which has
already been freed via `rte_free(new_rx_buf)`.
[Actual Results]
Currently, this does not immediately trigger an exploitable Use-After-Free
(UAF) because the queue is rolled back and not marked as "active/added" in this
specific lifecycle phase. However, leaving a dangling pointer is a classic
anti-pattern that severely damages code robustness. If `queue_info` is reused
or retried in the future, it might lead to a latent Use-After-Free.
[Expected Results]
Pointers should always be safely cleared when the memory they reference is
freed, or resource attachments should only happen after all potential
allocation failures have been safely cleared.
[Suggested Fix]
Option A: Simply reset the pointer to NULL immediately after freeing the memory
in the error block:
```c
if (stats == NULL) {
rte_free(new_rx_buf->events);
rte_free(new_rx_buf);
queue_info->event_buf = NULL; /* Avoid dangling pointer */
...
return -ENOMEM;
}
```
Option B (Preferred): Postpone the pointer assignment until all allocations
(including stats) have fully succeeded:
```c
/* Move this assignment down, after the stats NULL check */
queue_info->event_buf = new_rx_buf;
```
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2026-09-10 12:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-2034-3@https.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.