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>
next prev 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.