|SUCCESS| [v2] net/memif: fix use after free on listener socket close

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Fri Nov 6 16:33:07 CET 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/172699

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-11-06

# DPDK Patch Review

## Patch Summary
This patch fixes a use-after-free bug in the memif driver by replacing `rte_intr_callback_unregister()` with `rte_intr_callback_unregister_sync()` to ensure the interrupt handler completes before freeing resources.

## ERRORS

None identified.

## WARNINGS

None identified.

## INFO

**Code correctness - use-after-free fix is correct:**

The patch correctly identifies and fixes a use-after-free race condition. The original code:

```c
rte_intr_callback_unregister(socket->intr_handle,
    memif_listener_handler, socket);
rte_intr_fd_close(socket->intr_handle);
rte_intr_instance_free(socket->intr_handle);
```

If `memif_listener_handler()` is executing when `rte_intr_callback_unregister()` is called, the unregister returns `-EAGAIN` but the code continues to close and free the handle while the handler is still running. The fix uses `rte_intr_callback_unregister_sync()` which blocks until the handler completes, preventing the use-after-free.

**Both call sites updated:**

The patch updates both locations where this pattern occurs:
1. Line 1129: error path in `memif_socket_init()`
2. Line 1201: in `memif_socket_remove_device()`

Both changes are necessary and correct.

**Appropriate synchronization method:**

Using the `_sync` variant is the correct approach here since:
- The code is in a control path (device removal/cleanup), not a performance-critical fast path
- The resources (fd, handle) are being freed immediately after unregister
- Blocking to wait for handler completion is acceptable in this context

Review-Result: CLEAN


More information about the test-report mailing list