All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@google.com>
To: Kamil Sawicki <user148783812897@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@kernel.org,
	 kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	 willemdebruijn.kernel@gmail.com
Subject: Re: [PATCH net v2] net: limit priority VLAN untag depth
Date: Tue, 27 Oct 2026 01:40:04 +0000	[thread overview]
Message-ID: <auAA6ww0o6W07hGF@google.com> (raw)
In-Reply-To: <20261024004835.17862-1-user148783812897@gmail.com>

On Fri, 23 Oct 2026 20:48:35 -0400, Kamil Sawicki wrote:
> The priority VLAN receive path can repeatedly remove VID 0 tags and retry
> packet processing. Unlike the read-only VLAN protocol parser, this path has
> no limit on the number of nested tags it consumes.
> 
> Each skb_vlan_untag() advances skb->data and resets header offsets. The
> offsets are stored in 16-bit fields. With enough nested tags, the network
> or transport offset can wrap. A later protocol handler can then derive a
> large pull length from the wrapped offsets and access memory outside the
> skb allocation.
> 
> Apply the existing VLAN_MAX_DEPTH limit to the exceptional VID 0 retry.
> Count the tag already stored in skb VLAN metadata as the first level, then
> stop before untagging a ninth level. Keep the accounting inside this
> uncommon branch so the regular VLAN receive path is unaffected.
> 
> A single VID 0 priority tag before a real VLAN tag is valid. No normal
> deployment was found that intentionally emits multiple consecutive VID 0
> tags; permitting eight levels is therefore conservative.
> 
> The issue was found while researching the Linux network receive path for
> Google kvmCTF, with OpenAI Codex (gpt-5.6-sol) assisting the analysis. The
> affected path, reproducer and fix were manually reviewed and tested.
> 
> Fixes: 36b2f61a42c2 ("net: handle 802.1P vlan 0 packets properly")
> Cc: stable@vger.kernel.org
> Reviewed-by: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Kamil Sawicki <user148783812897@gmail.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>

  parent reply	other threads:[~2026-10-27  1:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24  0:48 [PATCH net v2] net: limit priority VLAN untag depth Kamil Sawicki
2026-10-24  8:22 ` Eric Dumazet
2026-10-27  1:40 ` Kuniyuki Iwashima [this message]
2026-10-27  7:06   ` Eric Dumazet
2026-10-27 22:40 ` patchwork-bot+netdevbpf

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=auAA6ww0o6W07hGF@google.com \
    --to=kuniyu@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=user148783812897@gmail.com \
    --cc=willemdebruijn.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.