From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E3E737B40E for ; Sun, 19 Apr 2026 13:01:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776603699; cv=none; b=AAX10T5zdknuJpPN5gM1HTgKsiGZC0Z4EtWal6hHOySLLWB6Wb/RZVGho/AHS8y0nmT6L9gfQbmTDIRQ+70WAlQqhsLKQFNEdCJ+US8eEwQ44RfrVnmlFVfdRt31D/zw6kzw/zfLd3c9NlmqIgGP4dx2Sr012bmmAfetxUmPMVM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776603699; c=relaxed/simple; bh=pX5EvkDZNatuuN3n/U7mYJ/WQU/4SAOnlLh4teqFHLw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iXxvWqmMCxM1I1RlTVUXYX+H8BVOJL2y6kReo+VTm5cgf8J9WLz3LEofpFajJ/HfjmfQO95SsA9NIyCXyMLPUjfO1RQspH+R9pQ3y1TjTsqQd20PIvmgJEEKCQ/QhwOsvhinQftQOuxmQyu5whOJvHb5UoTnxlIVAO981X6Pfpo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=rJFMTZZy; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="rJFMTZZy" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776603695; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ELsZ4zsAX7/4xYOMb704nnpfFkN1la3I7mXql9fMiGY=; b=rJFMTZZyu0DARjLvx7zpKKNR9LRUtHiT1HhzXqtlU8YGrpEEG2KPWyUMs7MDDIhpCGlifZ TKOfXpNRi3ijtuRt7qKaANH2prg7u/9ixSC/8VKp0s66nsCfsm5YjXeS96RXImpjSh5t5a fluyvdsZzXvctGE5ODWm03qeBFnF1r4= Date: Sun, 19 Apr 2026 21:01:26 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net v2] net: iptunnel: fix stale transport header after GRE/TEB decap To: Eric Dumazet , Jiayuan Chen Cc: netdev@vger.kernel.org, syzbot+83181a31faf9455499c5@syzkaller.appspotmail.com, "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Pravin B Shelar , Tom Herbert , linux-kernel@vger.kernel.org References: <20260419090817.127334-1-jiayuan.chen@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT [...] >> +662,18 @@ static inline int iptunnel_pull_offloads(struct sk_buff *skb) >> return 0; >> } >> >> +static inline void iptunnel_rebuild_transport_header(struct sk_buff *skb) >> +{ >> + if (!skb_is_gso(skb)) >> + return; >> + >> + skb->transport_header = (typeof(skb->transport_header))~0U; >> + skb_probe_transport_header(skb); >> + >> + if (!skb_transport_header_was_set(skb)) >> + skb_gso_reset(skb); > I do not think this makes sense. > What is a valid case for this packet being processed further? > The buggy packet must be dropped, instead of being mangled like this. Hi Eric, The reproducer builds a gre frame whose inner Ethernet header is all-zero. Tracing the skb through RX: 1. At GRE decap exit, skb_transport_offset(skb) < 0 is the rule, not the exception. It is negative for every packet leaving the tunnel, including perfectly well-formed inner IPv4 traffic because the tunnel leaves skb->transport_header at the outer L4 offset while pskb_pull() has already advanced skb->data past it. skb_transport_header_was_set() stays true, so downstream code that trusts that flag now trusts a stale, negative offset. 2. GRO repairs it — but only for protocols it knows. In dev_gro_receive(), skb->protocol is dispatched through the offload table. For ETH_P_IP, inet_gro_receive() calls skb_set_transport_header(skb, skb_gro_offset(skb)), and the offset becomes valid again. But for malformed skb, dev_gro_receive just bypass it. 3. Both kinds then reach __netif_receive_skb_core(). So the skb that qdisc/tc/BPF segmenters later see has an invariant violation — _was_set == true but offset < 0 — that the core layer has no intention of catching for us. My reading of this is that the tunnel decap path is producing an skb that doesn't honor the contract __netif_receive_skb_core() expects from its producers, and that it doesn't really make sense to ask GRE to parse or validate the inner L4 in order to fix this. I'm thinking at the end of GRE decap, before handing the skb to gro_cells_receive(), call skb_reset_transport_header(skb). Thanks, Jiayuan