From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f53.google.com (mail-yx1-f53.google.com [74.125.224.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C30B732B989 for ; Thu, 26 Mar 2026 03:12:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774494732; cv=none; b=PkL8DCv2vVA2hhguMpYtGMqjsFWd5eLlcRUaTw5acHzvV3Mjb8xH3KQhcd7N/eTnLP4ie0suTN1Iwn2VzSApUhTkjVzHF4YCcGsiUrDkviyhJgAQSWlb+2yu9iFhla840Gzgv3KXYEdZHtbTFX1EcOWFeM29mBFXlXvc1HTrIUg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774494732; c=relaxed/simple; bh=cxy4jPFKS+dxyEgCPzGebbTEv+fWYHGtoa7d4CzerZU=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=g5ErUDAgbVMPVZEp2VM8ZmHCGTquEbPWaEQcDCtAopvsfOI03zRcGLZQNycu+N8XMv6sODLavBJpymq/SDCy8clxjAjlHEUq4SskYY4y3vrRIy9QuF06ua2vrsjTsqG4DdSq/lwQrJxUc5wNL2is4RstB9oTxzI7D1gLZarLUXI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LpygMZB0; arc=none smtp.client-ip=74.125.224.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LpygMZB0" Received: by mail-yx1-f53.google.com with SMTP id 956f58d0204a3-64ee82e853cso455950d50.3 for ; Wed, 25 Mar 2026 20:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774494730; x=1775099530; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=vDOAPzrB5C4ZBYqCDQh23MerGG6Hzy4OJS0fb+WkGj4=; b=LpygMZB0CYGnR34hnf6GawWfoe7dlQAutDDvC+pPiEJAP5MUxXacuiwM0bdMYYfATx a0Ihwhug1zxIiDxDj0xq1SS+5L3Cp0hwWCh+1+z0gFZF3vgtHp0P3GsBV+kg/dBZgk3k cT0TFUNl07luA9ErjlXpRh61NOhUDVWg2LLaYJW589w7DSUL/WoJhzXJPYXZDJjRu6oM iGdja1SLXclKG+52W/tVktKxrf8X8LOFJ9Et3z9lcBxmwnXwhVqKXa+aL46rVJjrKH01 gIwiqIAbMTLh10TX2kBHuuM6mu27zBjdQxx10Yxpkk2SQ3eopGH5K9c5G3clsRrnB6wY 997Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774494730; x=1775099530; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vDOAPzrB5C4ZBYqCDQh23MerGG6Hzy4OJS0fb+WkGj4=; b=jYP5XKyPvMCzMUnlddGncEmkzXpbUGenQ/v0NmHxKrTh1cIaHX5HDql8MQjj9GuvJa cU4SQ5PU4dme/pQHjBL/gL9DfhfpyQL73LsAet825tYvRHwnUBF+l7OucN76kKw0u93+ lk8AeFj07cOXqmKQCmvcxx0qvSLgbBbRBHWotc3VYLyIUM5XEUzAIVno9GNoyel9ia/B KlQliS8VsbKKII+4LglzGWn3hl/Qddv52HKEt3ehraHFQOy1sTAWYiq50wJU/CazYxnP 6+3YpbNxDFyauOhN872rds0S7tT3W/BI/FLRUwiXzgcEtJ8GdVB1dZUNNb7chPqsv0Km tLTQ== X-Forwarded-Encrypted: i=1; AJvYcCWPW1nfeNdgFSlkzLjOVu0iUCUHqHuKBHDdt9N3eHfei2jwJQJo+UzajqsqAICf3G3Ue3KG6KAvJeic0Vk=@vger.kernel.org X-Gm-Message-State: AOJu0Yzj3YgXORVyALIwUh2BPvwnESAuE4yigUgSbw2usmY0EPcEfNB7 +SPj/p4aKJKW2xdlmY/mvZXG7bWwL6SOQF0ET6Hi6OwPpJKfPjCu0jR+ X-Gm-Gg: ATEYQzxegXzLKoc6pkAOzeEs8VbvSmGMDqlXBNwTkn7FjFqfObf+aS/cdFbQrdHLYKC PTlV6yQQu8CF18mFj3ifJo4HBr05SBZLbJl19dpfVB2NK5ccd86IEomi1KnoBaz96c9NMqVzX9u 5wEhJ3uGVJP2giCi8HfAw1ZNZlEfxiKRWnITS89OlsGcy9/5eAxKZ+HRR7z+7NsKYiSfWFTh4ns TgoYEvwJswFYZqcjWXJIm22NkbAKsi+lpMfvSCIFwKJt3Ouuc6OixVms54VsFOVzShtMn1LIXG4 tavx0inXLuLvw9yvZaKkf7UOmTmTUBbx6cMnlH39kF95k6Btw8YooGy3Azmk8IDbywkMAhO4f1y OHLNuw7UvDPqR86jG7LFpCfj69E6I8Pr5+gFADo+K/p/JHFvqbcSdwYDzNOSRSOvJdOkGqTFRKS WD141TOwt49goWvmTwXZ8DEnBgDCWH7L/uTHuQjRMRaH9ku+SO5i6PkBf+rdfbSoGG4pTFSjmna 3LN X-Received: by 2002:a05:690e:d0a:b0:64e:e0fc:a318 with SMTP id 956f58d0204a3-64ee6179f16mr5992798d50.66.1774494729710; Wed, 25 Mar 2026 20:12:09 -0700 (PDT) Received: from gmail.com (180.134.85.34.bc.googleusercontent.com. [34.85.134.180]) by smtp.gmail.com with UTF8SMTPSA id 956f58d0204a3-64ef6c36b73sm899042d50.19.2026.03.25.20.12.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 20:12:09 -0700 (PDT) Date: Wed, 25 Mar 2026 23:12:08 -0400 From: Willem de Bruijn To: Guoyu Su , Willem de Bruijn Cc: edumazet@google.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, horms@kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, syzbot+1543a7d954d9c6d00407@syzkaller.appspotmail.com Message-ID: In-Reply-To: References: <20260320141459.9691-1-yss2813483011xxl@gmail.com> Subject: Re: [PATCH net v5] net: use skb_header_pointer() only for DODGY TCPv4 GSO skbs Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Guoyu Su wrote: > > Perhaps you're running a different repro from the one I used. Which is > > the C repro from the run at commit ca4ee40bf13d. Thanks for verifying. > I reran with the exact ReproC from that run: > https://syzkaller.appspot.com/text?tag=ReproC&x=10e3fe5a580000 > (commit ca4ee40bf13d), rebuilt locally, and reran. > > > I see that the virtio_net_hdr has hdr_len 106 and csum_start 88. > > Those are fine. Same for your repro? > > Yes, same in my run as well: > vnet_hlen=106, vnet_csum_start=88 (first 20 dumps are consistent). > > > The question is how skb->network_header can be greater than > > skb->transport_header right after virtio_net_hdr_to_skb. > > From my instrumentation on the same skb in packet_snd(): > - packet_parse_headers() sets netoff from device L2 layout: > hard_hlen=172 on ip6gretap0, so netoff=172. I don't see this, but hard coding it gets the same issue. More importantly, I took a closer look at a fix. Unfortunately skb_network_offset cannot be trusted for link layers with variable length headers. With SOCK_RAW it is the worst case hard_header_length. PF_PACKET is network layer agnostic, and with SOCK_RAW on variable length link layer packets, nothing communicates this. So, a straightforward check like this may have false positives where a valid packet is shorter than this worst case estimation of network offset. @@ -103,7 +103,7 @@ static inline int __virtio_net_hdr_to_skb(struct sk_buff *skb, if (!skb_partial_csum_set(skb, start, off)) return -EINVAL; - if (skb_transport_offset(skb) < nh_min_len) + if (skb_transport_offset(skb) < skb_network_offset(skb) + nh_min_len) As a result, I don't see any test we can do at this point that will not have false positives. Only for GSO packets is there downstream code that requires the network header and that assumes this header starts at skb->network_header. __skb_gso_segment calls skb_reset_mac_len(skb) and parses the headers in skb_mac_gso_segment and skb_network_protocol robustly using skb_header_pointer and pskb_may_pull. We can at this entry point anticipate reaching that code and add an extra branch if gso_type. But might as well just make robust the one access in the GSO path that is not yet. So in short your original approach is probably preferable. Please do add a Link: to this thread. And one more thing: skb_header_pointer already takes the fast path of just returning the offset if within linear. No need to special case the DODGY vs non-DODGY path. ~ ~ ~ ~ ~