public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
Cc: <dev@dpdk.org>, <jgrajcia@cisco.com>, <stable@dpdk.org>,
	<bly454@gmail.com>
Subject: Re: [PATCH] net/memif: fix multi-segment RX data corruption and truncation
Date: Mon, 23 Mar 2026 16:33:04 -0700	[thread overview]
Message-ID: <20260323163304.71a6a785@phoenix.local> (raw)
In-Reply-To: <20260316155918.3756017-1-sriram.yagnaraman@ericsson.com>

On Mon, 16 Mar 2026 16:59:18 +0100
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> wrote:

> Fix dst_off being reset per-descriptor instead of per-packet in the RX
> slow path. When processing chained descriptors (MEMIF_DESC_FLAG_NEXT),
> goto next_slot2 reset dst_off to 0, overwriting the beginning of the
> current mbuf with data from subsequent descriptors. Move dst_off
> initialization before the next_slot2 label so it is only reset once
> per packet.
> 
> Add boundary check in both RX paths before processing next segment.
> If MEMIF_DESC_FLAG_NEXT is set but n_slots is 0, free the incomplete
> mbuf chain and exit gracefully to prevent reading beyond available
> descriptors.
> 
> Bugzilla ID: 1609
> Fixes: aa17df860891 ("net/memif: add a Rx fast path")
> Cc: stable@dpdk.org
> 
> Reported-by: Mike Bly <bly454@gmail.com>
> Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>

It looked good to me, but AI review spotted an issue.


---

OK, so my error finding stands but with refined reasoning. Here's the corrected summary:

**Error: Double free of `mbuf_head` in the fast-path truncation error path.**

In the new truncation check added to the fast path:
```c
if (unlikely(n_slots == 0)) {
    MIF_LOG(ERR, "Truncated packet: ...");
    rte_pktmbuf_free(mbuf_head);
    rte_pktmbuf_free_bulk(mbufs + rx_pkts,
            MAX_PKT_BURST - rx_pkts);
    goto no_free_bufs;
}
```

`mbuf_head` is `mbufs[rx_pkts]` (assigned at line 359). `rte_pktmbuf_free(mbuf_head)` frees the head and its entire chain. Then `rte_pktmbuf_free_bulk(mbufs + rx_pkts, ...)` processes the same array starting at `mbufs[rx_pkts]`, which still holds the now-freed pointer. Since `rte_pktmbuf_free_bulk` walks `m->next` chains (confirmed in `lib/mbuf/rte_mbuf.c:574`), this frees `mbuf_head` a second time.

The existing error paths at lines 383-386 and 391-394 do NOT have this bug — they don't call `rte_pktmbuf_free(mbuf_head)` first; they let `rte_pktmbuf_free_bulk` handle the entire chain. The fix is to remove the separate `rte_pktmbuf_free(mbuf_head)` and just do:
```c
rte_pktmbuf_free_bulk(mbufs + rx_pkts,
        MAX_PKT_BURST - rx_pkts);
```

This works because `rte_pktmbuf_free_bulk` already walks the chain on `mbufs[rx_pkts]`, freeing `mbuf_head` and all segments chained onto it, plus the remaining unused mbufs.

No other issues found. The `dst_off` fix and the slow-path bounds check are both correct.

  reply	other threads:[~2026-03-23 23:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 15:59 [PATCH] net/memif: fix multi-segment RX data corruption and truncation Sriram Yagnaraman
2026-03-23 23:33 ` Stephen Hemminger [this message]
2026-03-24 16:16   ` Sriram Yagnaraman
2026-03-24 16:14 ` [PATCH v2] net/memif: fix multi-segment Rx corruption Sriram Yagnaraman
2026-03-24 16:25   ` Stephen Hemminger

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=20260323163304.71a6a785@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=bly454@gmail.com \
    --cc=dev@dpdk.org \
    --cc=jgrajcia@cisco.com \
    --cc=sriram.yagnaraman@ericsson.com \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox