All of lore.kernel.org
 help / color / mirror / Atom feed
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.