From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.128.174 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793680322; b=IkYtm9N9b27943yVqXiqODuLOJbwVnm+lV2VLH2utQsV+zXV/ZCQYxnNzbdmuPVlAFSu PURSaaG4wL2ByKjgW1C4/VK+UzzHxaz488e+hMD3/rr2liXjDNMugMzWOwmz03/8tQu8R CGBm2CjQN13tZ3KrIieSAaywseQAXt4zx1zoHkcFc/CrzUsO1FYED1pqWYJ1KzrmZJLXD xYDTxj9jnisQJ7wD/j1LYMWqxJUU4Dq7efwy662e9YtbsTcu4Orx/B6gNkZoefEjfwK1k 8Pt8TZVfU4dkiJuTeyU1BO8yZfv7jApUelE9W04e675MOXdpSgLeYYnOiDx/8eKp6KA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793680322; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References: Content-Language:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=K7cNTtUrlw/YMKMwg5CBdynxQMrMR2KfNh32rGFC1ZY=; b=GeKhfmpBJy58G8RQImt9jHRkkReP9soy87/zCATP2EV+ROaLhzyObWy5AilXkRovhMIZ B1ms8rYE8JpOorSLe8HnCCrLSxSgm+/rgCbnbq6oXDVzALqpuFJ4j2k42Is+x7w3IXGGK xB49vq/8u3pqoCxlSfaM1mPv6rR+arDDse5Ad+MsloVwwegFDyT84SoF+tkWheZHvHZ3i VNYcwnxTyemyQUsqVSJYFFJ7hLbL8Q4Gth7L1gWW0lpE1ltBD7ax1d5VdtMu9gQDUQSAM Pz7I5pfEt4A3YgiR9QF5LabpP4Wghj47Si+Yljy7+Z1IRXf2270PJV2NNyn0WAg7GCw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=ktumvrEO; arc=none smtp.remote-ip=209.85.128.174 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B0BE606A326 for ; Tue, 3 Nov 2026 04:32:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 2B0BE606A326 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, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=ktumvrEO Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-8b2d14968c9so18179747b3.0 for ; Mon, 02 Nov 2026 20:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793680320; x=1794285120; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=K7cNTtUrlw/YMKMwg5CBdynxQMrMR2KfNh32rGFC1ZY=; b=ktumvrEO/Fbgzz7BIo6zVcbBwrh+0p6lniANqwz9XiF5UUrx6AzNtvrP4n3lQgIZ60 bopGYYFy7FGc6Sho8pAzyzese7akl1eiSvSbp8gDMbtL9OWs9pyZ0nRA5sbQ79zZT1D/ tVhENVdr8sKUkUuSL+rLvkHuCzQP/+IxnqxvOleLDCWhB+DWtCcGD7jnAY5hdN9kcN/8 PvmAQ+p9CtoGZEQCNSbO+ExnIOdqfNpr1e3KpTZ8bFxOk5JjqQ4r0dR4QLZKQbiMK0Iq 6gvmMR42DaWcJsPg/oNcytcRHbRV6DvqVQyLKZ98ne8SPuOKemECxWzst9RzyqaRuyxa p5Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793680320; x=1794285120; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=K7cNTtUrlw/YMKMwg5CBdynxQMrMR2KfNh32rGFC1ZY=; b=RVUsqI4QkhAjyuDY01taQhVYaFHC+dct7jk/SKHF2ztmpBbMk+Z4lgpn0/K0sUFMVN gkdmvvMXPfkcd+zHYSEru8T9noEYqnuQV+AtgRReMzYK719UJx9Iz/yodJWXyHigc05/ L4hKsD6wgMUtez67RYu4DFQ5kK/UKv7fSbgksygQUlsjYvaN5sD+bOrzUn3fv1FPENH+ OEn1gwbQwnX32A57kN997fKLMncufUUC3cYyYcrH6X424vrfwrQ7ZJHRdFXKc5g19+Fo JaI45lh35UwTYgh8eR3shXtx0xgOoO4K3RerC+5xKKW65/90UMMtTgeac8XAiAJiKZfl 1spg== X-Forwarded-Encrypted: i=1; AKwUvBzJmsQnCccks7C8ArJVUr8nBkmeV4qnHiSrHkGMwY0APyCV7RxHi47YGxAUW5h8IzbZGBSzY1U=@vger.kernel.org X-Gm-Message-State: APuU4Z/UcBzB58/jY+0cC+VHWt7U6XWFrAuUTEParOgcSPgWhAu1uf3E r1H2yOjCwFJEuCa1yjMR/1v08QRxw46CNjOz5ExLfY//bH8z1fP8PlNu X-Gm-Gg: AYBFou2xBdFGv1IGrZCNo7O/Z3ub56p6WANx0VZ94yZHzP0NBofWkhRsmdiN821BjtF wTc4ophIrov4nP47/wapqCMb5vcIPGgb4qBUyIa7QT9bZepqmHdf1V6hpi2S0ze7+S3soFPYUw3 tqVyZtGYNk5WZA0pjqSKDAsPknLGk8UGb0n59IYI0ciXktJY+emtktQZUPD5f/HMnUkfsi4OBDn M/5ZsYKCO1xF9+2y4St48+NU/GcJDk6ZsLvQLeIHEWhHDDnc94hk2B0RFDsAVXML/XWBJcwvNjl iOojqYykw7JgUniY/RwY48BLNRrpFEx4qCsmwkZ1HRSYdXlVkZY2why7JpX/YAolHtR+i7yKQoM rsX2gGq0u6Olq6uZM+erL53w5+GCQJuQHLss+/88fCCNybJvXB86/07z/hvwBtQZ/lKj1dVAF77 MHLPI+skdJSoJXRcJNT+Gb9JTdQWqXvY+KHHajzz9Up56DQzsNQmRPRAgnxNc8nn5ywKKzMH5zt PpPn7omdYqxBR85NZ+lELwzcDkE8hlMpg1SFy/onsE9hntMmlVXc+0qUd7TepPt4sZekSLBk+tB xt/H6KvQQQrb7VK1kYFUxPi1SxlHnvCaln2k0e9bWyY2J4zkj0r7SzQ/S42h84fu+YSJY1s= X-Received: by 2002:a05:690c:a401:20b0:873:5c6b:a305 with SMTP id 00721157ae682-8b2b678564cmr58378467b3.51.1793680320144; Mon, 02 Nov 2026 20:32:00 -0800 (PST) Received: from ?IPV6:2600:6c5c:6b00:316::23? ([2600:6c5c:6b00:316::23]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b2b71657besm65304927b3.30.2026.11.02.20.31.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Nov 2026 20:31:59 -0800 (PST) Message-ID: Date: Mon, 2 Nov 2026 23:31:57 -0500 X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH iwl-net v2] e1000e: fix Tx descriptor field wrapping To: Alexander Duyck Cc: intel-wired-lan@lists.osuosl.org, Tony Nguyen , Przemek Kitszel , netdev@vger.kernel.org, Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Andre Brait , stable@vger.kernel.org References: <20261028170239.28606-1-tactii@gmail.com> <31444b89635e8520c262ae915235991c3c075a0a.camel@gmail.com> <8df82d18-da9e-4077-8ed4-316e5314882a@gmail.com> Content-Language: en-US From: Matt Vollrath In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/31/26 12:53, Alexander Duyck wrote: > On Fri, Oct 30, 2026 at 12:00 PM Matt Vollrath wrote: >> >> On 10/29/26 12:47, Alexander H Duyck wrote: >>> On Wed, 2026-10-28 at 13:02 -0400, Matt Vollrath wrote: >>>> When an skb arrives at the driver and the header length exceeds the u8 >>>> hdr_len, tucss and tucso fields in e1000_context_desc, wrapped values >>>> are sent to the card. If TSO is enabled, some header lengths will cause >>>> the card to hang. >>>> >>>> This was reproduced on an I218-V with an unprivileged Python script. >>> >>> Can you elaborate on what the script did to trigger this? I am >>> wondering if it can even get there with a valid frame supported by the >>> interface since most of these e1000e parts don't support tunnels and >>> such. >> >> I will send you the script OOB. To be clear, this is a security fix, >> not a correctness fix for rarely used paths. The rules say I have to >> post the fix publicly because an LLM found it in a >> function-by-function scan. > > I got the script, will try to take a look at it over this weekend. > >>> Also did it have separate cases for the CSUM vs the GSO? I would >>> suspect this is more a CSUM issue than a GSO issue. >> >> I have only reproduced hardware hang when TSO is enabled on the nic. >> Otherwise it likely just mangles the packet, but I have not confirmed >> that. >> >>>> Fix it by disabling GSO and checksum offload when the header length (and >>>> checksum offset) would exceed the field widths. Compensate for a >>>> software-inserted VLAN tag. >>>> >>>> Because of a quirk in the ordering of ndo_features_check, the skb's >>>> transport_header field may be stale. If the skb carries >>>> CHECKSUM_PARTIAL, use csum_start to find the header. Otherwise, there's >>>> no reliable interface, so don't offload it. >>>> >>>> Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") >>> >>> I am pretty sure this Fixes tag is bogus. This is the introduction of >>> the e1000e driver which was in 2007. The ndo_features_check didn't >>> exist until 2014 sometime after that if I am not mistaken. >> >> My understanding is the Fixes tag should point at the commit where the >> bug was introduced. A comment on the Cc: stable tag indicates how far >> back the fix can backport. I didn't bother because this patch should >> apply back to 5.0 (skb_is_gso_tcp()) and the oldest LTS is 5.10. > > I get that, but at the same time the fixes tag is pointing at the > driver when what more likely happened is that the stack evolved past > what the driver can handle as evidenced by the fact that the fix would > never be able to backport that far as the function it was adding was > introduced sometime after the additional stack complexity was added. The Fixes tag seems correct to me. To confirm it I reproduced the hanging hdr_len values against 2.6.24 on top of Fedora 8. It was more or less the same script, just with different headers. I can't confirm that it hangs the limited set of hardware supported in the first driver commit. Maybe Intel could test it in their lab. It's worth finding new core complexities causing problems in drivers, but in this case the mechanism predates the driver. It really has been a security bug for 19 years. The switch was enabling TSO6 when e1000e was spawned from e1000. The fix not being able to backport all the way to the Fixes tag was a choice. It has nothing to do with the bug not being a bug that far back. I'm not spending time supporting Linux 2.6 or any pre-LTS kernel, nor is anybody at Intel or kernel.org, as far as I know. The attack surface and details of exploit have changed over time, but that's not a story that a single Fixes tag can tell. It's the story of IPv6 headers. >>> Much of the complexity that enabled frames to build up massive headers >>> wasn't until much later when the network tunnels and OVS started being >>> added. >> >> The repro script should work back to 4.10. > > Okay. However, that still only goes back as far as 2017 if I am not > mistaken. The diff you are blaming is from 2007. I suspect we should > be looking at blaming whatever introduced the ability to push the > headers this far as the driver itself isn't likely the root cause for > the issue, but instead a header change was. > >>>> Cc: stable@vger.kernel.org >>>> Assisted-by: LLM >>>> Signed-off-by: Matt Vollrath >>>> --- >>>> drivers/net/ethernet/intel/e1000e/netdev.c | 34 +++++++++++++++++++++- >>>> 1 file changed, 33 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c >>>> index 6f85dab5c55c5..370776657d100 100644 >>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c >>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c >>>> @@ -7355,6 +7355,38 @@ static int e1000_set_features(struct net_device *netdev, >>>> return 1; >>>> } >>>> >>>> +static netdev_features_t e1000_features_check(struct sk_buff *skb, >>>> + struct net_device *netdev, >>>> + netdev_features_t features) >>>> +{ >>>> + /* Do not offload packets whose header lengths exceed the u8 fields >>>> + * in the descriptor. >>>> + */ >>>> + unsigned int hdr_len = 0; >>>> + >>>> + if (skb->ip_summed == CHECKSUM_PARTIAL) { >>>> + const struct tcphdr *th = (const void *)skb_checksum_start(skb); >>>> + >>>> + hdr_len = skb_checksum_start_offset(skb); >>>> + if (skb_is_gso(skb) && skb_is_gso_tcp(skb)) >>>> + hdr_len += __tcp_hdrlen(th); >>>> + else >>>> + hdr_len += skb->csum_offset; >>>> + } else if (skb_is_gso(skb)) { >>>> + /* Work around untrustworthy header offsets in this case. */ >>>> + return features & ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK); >>>> + } >>> >>> Most drivers currently assume if the CHECKSUM_PARTIAL isn't set then >>> the frame must not be TCP/UDP GSO since for those normally the checksum >>> and offsets should be populated. Have you identified cases where we are >>> seeing TCP/UDP GSO w/o the checksum being set up? >> >> It looks like this particular case is never reached by normal traffic. >> It has to be GSO without NEEDS_CSUM. This is only produced by a buggy, >> hostile or niche setup. >> >> When CHECKSUM_PARTIAL is not set, the csum_start/csum_offset fields are >> used for csum instead, or left zeroed. >> >> The transport_header field is unreliable when a packet is being routed, >> so you would need to parse the packet from the top to find where the >> transport header ends. >> >> Rather than walk all the headers for hdr_len, it seemed prudent to just >> categorically deny offload for these exceptional cases. I could be >> convinced otherwise. > > The point I was trying to get at is that the stack shouldn't be > allowing those sort of frames through in the first place. Basically if > checksum partial isn't set the stack should be rejecting the frame for > UDP/TCP GSO, not the drivers. I agree that this patch demonstrates how obtuse it is for an ndo_features_check to reliably measure header length, which is something that several drivers need to do in the hook. The issues being worked around should be fixed in core. GSO without NEEDS_CSUM is the biggest offender, no driver is checking for that in their implementation of ndo_features_check. Using a potentially stale transport header is next in line. Several drivers are getting this wrong. I'm working on a fix, a simple reorder. >>> From what I can tell it looks like the only valid cases for it not to >>> be set and instead it is set to CHECKSUM_UNNECESSARY on a GSO frame are >>> FCoE and SCTP (GSO_FRAGS) which are both non-TCP/UDP specialty cases >>> anyway. >> >> FCoE was switched to CHECKSUM_PARTIAL in 253aab0597d9e > > This is part of the problem. It pushed through the ability for > CHECKSUM_UNECESSARY to be valid in an outgoing TCP frame, and then was > reverted back to using CHECKSUM_PARTIAL. That is what is partially > what is allowing the non-partial checksum through for GSO frames. > > I will probably look at submitting a diff for this next week to look > at limiting this as there are a number of drivers that already expect > all TSO/USO frames to have CHECKSUM_PARTIAL always set before they > start processing the frames. That would be great.