DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Robin Jarry <rjarry@redhat.com>
Cc: dev@dpdk.org, David Marchand <david.marchand@redhat.com>
Subject: Re: [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags
Date: Tue, 2 Jun 2026 13:43:41 -0700	[thread overview]
Message-ID: <20260602134341.5d7cd7fd@phoenix.local> (raw)
In-Reply-To: <20260518132712.70913-10-rjarry@redhat.com>

On Mon, 18 May 2026 15:27:16 +0200
Robin Jarry <rjarry@redhat.com> wrote:

> The VLAN and QinQ code paths in rte_net_get_ptype handle at most two
> tags with duplicated logic. Replace them with a single loop that
> consumes all consecutive VLAN/QinQ headers regardless of depth.
> 
> Bugzilla ID: 1941
> Suggested-by: David Marchand <david.marchand@redhat.com>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>

Another issue discovered by AI is that hdr_lens->l2_len is too small.

Patch 2/5: net: support multiple stacked VLAN tags

Warning: hdr_lens->l2_len is uint8_t. The previous code capped the tag
count at RTE_NET_VLAN_MAX_DEPTH (8), bounding l2_len to 14 + 8*4 = 46.
The new do/while consumes tags until rte_pktmbuf_read() fails, so the
only bound is packet length. A frame carrying >=61 stacked VLAN/QINQ
tags (>=244 bytes of L2 headers) wraps l2_len around 256. There is no
infinite loop or OOB read (off advances monotonically and the read
terminates at end of data), but the wrapped l2_len is exactly the kind
of bad header-length value this series set out to fix in tap_verify_csum.
Consider keeping a depth cap, or widening/saturating l2_len.

  parent reply	other threads:[~2026-06-02 20:45 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22 10:28 [PATCH dpdk] net: fix L2 ptype assignment in VLAN loop Robin Jarry
2026-04-22 10:35 ` Robin Jarry
2026-04-22 10:38 ` [PATCH dpdk v2] " Robin Jarry
2026-04-22 13:16   ` Thomas Monjalon
2026-04-22 13:18     ` Robin Jarry
2026-04-22 13:23   ` David Marchand
2026-04-22 13:32 ` [PATCH dpdk v3] net: fix VLAN packet type Robin Jarry
2026-04-23  9:19   ` Kevin Traynor
2026-04-23  9:49     ` Robin Jarry
2026-04-23 10:59       ` Kevin Traynor
2026-04-23 11:11         ` Robin Jarry
2026-04-23 11:24 ` [PATCH dpdk v4] " Robin Jarry
2026-04-24 16:18   ` Kevin Traynor
2026-04-25  8:40   ` David Marchand
2026-04-27 10:47     ` Robin Jarry
2026-04-27 15:53       ` Thomas Monjalon
2026-04-30 10:12         ` David Marchand
2026-04-30 11:06           ` Morten Brørup
2026-05-15 11:17     ` Kevin Traynor
2026-05-18 13:27 ` [PATCH dpdk v5 0/5] Fix and improve VLAN/MPLS parsing in rte_net_get_ptype Robin Jarry
2026-05-18 13:27   ` [PATCH dpdk v5 1/5] Revert "net: fix packet type for stacked VLAN" Robin Jarry
2026-05-20  9:47     ` David Marchand
2026-05-20 10:24     ` Kevin Traynor
2026-05-18 13:27   ` [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags Robin Jarry
2026-05-20  9:56     ` David Marchand
2026-05-20 11:09       ` Robin Jarry
2026-05-20 12:42         ` David Marchand
2026-05-21 13:38           ` Kevin Traynor
2026-05-21 13:38     ` Kevin Traynor
2026-05-21 13:40       ` Robin Jarry
2026-06-02 20:43     ` Stephen Hemminger [this message]
2026-05-18 13:27   ` [PATCH dpdk v5 3/5] net: add unit tests for rte_net_get_ptype Robin Jarry
2026-05-18 13:27   ` [PATCH dpdk v5 4/5] net: parse L3 protocol after MPLS labels Robin Jarry
2026-05-18 18:00     ` Stephen Hemminger
2026-06-02 20:44     ` Stephen Hemminger
2026-05-18 13:27   ` [PATCH dpdk v5 5/5] net: add truncated packet tests for rte_net_get_ptype Robin Jarry
2026-06-02 20:45   ` [PATCH dpdk v5 0/5] Fix and improve VLAN/MPLS parsing in rte_net_get_ptype 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=20260602134341.5d7cd7fd@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=rjarry@redhat.com \
    /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