[PATCH net v2] net: limit priority VLAN untag depth

[PATCH net v2] net: limit priority VLAN untag depth

[Kamil Sawicki]

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>
---
v2:
- rename vlan_depth to priority_tag_depth
- report SKB_DROP_REASON_RECURSION_LIMIT when the limit is reached
- address the expected real-world tag depth in the commit message

v1: https://lore.kernel.org/netdev/20261023003750.1133904-1-user148783812897@gmail.com/

Runtime-tested on net/main f4377bf85887 (7.3-rc7) with KASAN. The
patched kernel blocked the nested vhost/TAP trigger on five fresh boots;
each run recorded eight skb_vlan_untag() calls, no tcp_v4_rcv() call and
no KASAN report. The eight-tag packet was delivered, the nine-tag packet
was dropped, and kfree_skb recorded SKB_DROP_REASON_RECURSION_LIMIT for
all three nine-tag test transmissions.

The fragmented-head test stopped after eight untag calls without reaching
IPv4 or TCP. A 100,044-byte nonlinear GSO skb crossed two VID 0 tags, and
a 32 MiB BIG TCP transfer completed with matching hashes and skb lengths
up to 130,376 bytes. The 31-sample protocol-253 control recorded no matching
skb_copy_and_csum_bits() call and no shadow-probe hit.

Rebased onto current net/main 734bef548a96 without changing the patch-id.
Strict checkpatch and W=1 net/core/dev.o builds using allyesconfig and
allmodconfig completed without warnings.

 net/core/dev.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 1a09e786911805..c9f07beee25782 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6306,6 +6306,8 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
 	}
 
 	if (unlikely(skb_vlan_tag_present(skb)) && !netdev_uses_dsa(skb->dev)) {
+		unsigned int priority_tag_depth = 1;
+
 check_vlan_id:
 		if (skb_vlan_tag_get_id(skb)) {
 			/* Vlan id is non 0 and vlan_do_receive() above couldn't
@@ -6317,6 +6319,12 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
 			 * 802.1Q or 802.1AD and vlan_do_receive() above could
 			 * not find vlan dev for vlan id 0.
 			 */
+			if (unlikely(priority_tag_depth >= VLAN_MAX_DEPTH)) {
+				drop_reason = SKB_DROP_REASON_RECURSION_LIMIT;
+				goto drop;
+			}
+
+			priority_tag_depth++;
 			__vlan_hwaccel_clear_tag(skb);
 			skb = skb_vlan_untag(skb);
 			if (unlikely(!skb))

base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
-- 
2.53.0

Re: [PATCH net v2] net: limit priority VLAN untag depth

[Eric Dumazet]

Le sam. 24 oct. 2026 à 02:49, Kamil Sawicki
<user148783812897@gmail.com> a écrit :
>
> 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: Eric Dumazet <edumazet@kernel.org>

Re: [PATCH net v2] net: limit priority VLAN untag depth

[Kuniyuki Iwashima]

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>

Re: [PATCH net v2] net: limit priority VLAN untag depth

[Eric Dumazet]

Le mar. 27 oct. 2026 à 02:40, Kuniyuki Iwashima <kuniyu@google.com> a écrit :
>
> 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>

Reviewed-by: Eric Dumazet <edumazet@kernel.org>

Re: [PATCH net v2] net: limit priority VLAN untag depth

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 23 Oct 2026 20:48:35 -0400 you 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.
> 
> [...]

Here is the summary with links:
  - [net,v2] net: limit priority VLAN untag depth
    https://git.kernel.org/netdev/net/c/d3ff07f5acc5

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html