|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