|WARNING| ip_frag: fix IPv6 fragmentation of short packets

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Mon Oct 19 12:48:09 CEST 2026


Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/171629

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-19

# DPDK Patch Review

## Patch: ip_frag: fix IPv6 fragmentation of short packets

This patch addresses a buffer handling issue in `rte_ipv6_fragment_packet()` where short mbufs with `data_len < 40` (size of IPv6 header) cause integer underflow and infinite loop.

---

## ERRORS

**Integer underflow and out-of-bounds writes**

The patch description correctly identifies the bug:
With `data_len < 40`, the expression `(in_seg->data_len - in_seg_data_pos)` underflows because `in_seg_data_pos` (which starts at `sizeof(struct rte_ipv6_hdr)`) is greater than `in_seg->data_len`.

Quote from the existing code (not shown in the patch but described):
```c
in_seg_data_pos = sizeof(struct rte_ipv6_hdr);
/* ... */
(in_seg->data_len - in_seg_data_pos)  /* underflows when data_len < 40 */
```

This is a correctness bug: the underflow produces a very large unsigned value, the loop never terminates, and the code writes fragments past the end of `pkts_out`, causing a buffer overflow.

**The fix is correct**: the added check rejects packets with `data_len < sizeof(struct rte_ipv6_hdr)` before `in_seg_data_pos` is computed, matching the IPv4 version's behavior.

---

## WARNINGS

None.

---

## INFO

**Code style: explicit comparison**

Line:
```c
if (unlikely(pkt_in->data_len < sizeof(struct rte_ipv6_hdr)))
```

This is already in the correct explicit comparison style (`data_len < sizeof(...)` not `!data_len`). No change needed.

**Consistency with IPv4**

The patch notes that `rte_ipv4_fragment_packet()` has a similar check. This is good practice -- symmetric validation across IPv4 and IPv6 code paths reduces the chance of divergent bugs.

**Error code choice**

Returning `-EINVAL` for malformed input is appropriate and matches the existing validation in the function (MTU check) and the IPv4 counterpart.

**Comment quality**

The added comment clearly explains why the check is needed and what would go wrong without it. This is excellent documentation for future readers.

---

Review-Result: ERROR


More information about the test-report mailing list