From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (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 59F0F433038 for ; Wed, 12 Aug 2026 13:31:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786541463; cv=none; b=NOSCImWDP6zaWV+VOsLNipYkhOM96MAoicnzezXpw5+9vzgoMgN3J/eeosB2IhJJ8LzmiFeV/ZJ4y0VRJhROd9n9TeLvb2ymSciyljt8k9HFOUhNATNyVLB27qcXJvSnd1IPWLr7Ls7KPgrxmSbfhFiPDw/4pG7cUayJVRCA+ck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786541463; c=relaxed/simple; bh=ICMnfMcH2LL3xN8p4YnFuCah6rwJig7AYg2KFmZFBLU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uLe+evPbeOX6MEc8JAGF0sKc8z66KmKlHIVeIsLOVLfvDtHHZUYj122PJuKOrGojeZI7fry74NJhoJBWqok+COcuX5DwggmjMpMAIDvF0wzrPd+xwYH64v4uEsOWym/iVuhCngDBKiMvR8TSt1HTPXJZNcELwRbqNYhg9ybFCjk= 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=LnVqs405; arc=none smtp.client-ip=209.85.210.171 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="LnVqs405" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-84e0688b7e8so903505b3a.1 for ; Wed, 12 Aug 2026 06:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786541461; x=1787146261; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Uz+bfGVw3BN4xTVdoh1TluUgeBOBBwVoF8DrIGsXOfg=; b=LnVqs4055hualI/8Vsx7uXP+D6qqabnTYVO7bmcaV/TDMKt/aa4IeZ1uDBhZTtcXT3 R0OKVYV/X35a6VynsI67hZjg7bLZ6aH8GPmte32Kheffmv1vaTu+cJR5xphZUEw7yv+C EDBlLtLtqPEdvday56lhT0oTgtWn85o06yLpP/k8xHnO2tTDPE443Yq9gertDFHUQTCX +y5Cb8TF4MB2U7bax7ia9qIwGqBnvE1CdboVdbMubL+obRU6mOEq5nYLSR7yjUjFNfnO 1z1L/w2xYSFIsA7FUFZH7gcAoWo51Vbp1RXPpfq8VOqlYsL0T1qjCXBLk2jrVnmoe1hm qnlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786541461; x=1787146261; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Uz+bfGVw3BN4xTVdoh1TluUgeBOBBwVoF8DrIGsXOfg=; b=O1NrDMbufurikoLlKGSsxkLjKRfvizbZrLvDsqrqu73QobNhwX0MxE9y0J6OBotKql I+WDt8CjeRKzAZzZLAQwW4qogUlCZO58YYiBWAIXUHud+HMYGcLWqutxMqGNDv0CpxbU m5p8oVD0yplBD0ON3RtJhkhF6y0Pp7xngn5VzpoPSho0RXHxcl8QAUEK+MneC6b5Hx2P N06y/f9uiO2uf9VHIhtPJ33TXRHnhgeMB/e8jqAxBVBsM/LSbWxStdZb2+gixnQqdX// K1kAlw2XI6kwsZcXUfywpsyOB08RuW1EA/QzXi+kZ8FeAW1Ti+0iNQElximKg5WDR6Qo F6dw== X-Forwarded-Encrypted: i=1; AHgh+Ro4F55hjN2Xy77pnlrV+Xbb8xDOdfRnp73nflXziAWd1LoqYw/XbFmx5i3qts5DYl8WsW66SDd9XNgoZ/o=@vger.kernel.org X-Gm-Message-State: AOJu0YwJXLp45vf4jD7yMWCjgSA7WLV4Z4J15sT6UYZqAxqgTl4SAJhJ boIkf8JdeVlyLwe6PnWNqEUrfbOwmMQDGNARIL0Tl/g6rSz4US/dHnn5 X-Gm-Gg: AR+sD13XPgVTNnLNSwafnZ6oIsh7+eepaATngKeCUMaF1CeRd/4dYSR8CefuBt5uq53 KM5FVCtsJTBgFLecpIqhUKnhIAxGmUR1fYBX44brKbTSGLbo55oWcBeyKO+Y+9O+Z/G1UQmd8dV 3OAsUunXJTD9ZJ+9/EUH16p2Iib6QNNuPOjEF2BfbgyXkdtgLGqGeCzBM4CUG93MkT33rtAcxIe s2fd5iU+RzclJaHuumxd0tYPD3JAaw7eb0guv0/NWXr2E4k6giKI0DS+Q3bXY5f36UEaJ/0ID6N /A25Sgb88uNMZ5f6BBQpYKaXq9SVlyIZRCq+CMj3RDJ2XRawkF3jingIPFIjrytAUqoMrBbIZ3T CJrQbJP/OLGMj8Egr2SPoBMQEwtYDz728qis8H0I91+rWXWVB3mXMwW7z2OOlT7M5KxNQKvvHK0 PuD22Vd+0lP6KqXvDHuH/OxxrNxsgfKyqCwofzeJsKj6VRYG5iz0EugVE5v4RFd42ICA== X-Received: by 2002:a05:6a00:9515:b0:847:99bb:b6d8 with SMTP id d2e1a72fcca58-84fb553c24bmr5293712b3a.26.1786541460521; Wed, 12 Aug 2026 06:31:00 -0700 (PDT) Received: from user ([2405:201:c052:b00b:f326:be2a:1bb0:bade]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84fb1ee8bdcsm1046727b3a.39.2026.08.12.06.30.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 06:30:59 -0700 (PDT) Date: Wed, 12 Aug 2026 19:00:25 +0530 From: Yalagada Pavan Kumar To: "Loktionov, Aleksandr" Cc: Malathi , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , "netdev@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "kuba@kernel.org" , "pabeni@redhat.com" , "edumazet@google.com" , "andrew+netdev@lunn.ch" , "davem@davemloft.net" , "linux-kernel@vger.kernel.org" , "syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com" Subject: Re: [Intel-wired-lan] [PATCH net-next v2] e100: fix shift-out-of-bounds in e100_eeprom_load() Message-ID: References: <20260811050753.234931-1-malathi.a2000@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Aug 12, 2026 at 09:44:08AM +0000, Loktionov, Aleksandr wrote: > > > > -----Original Message----- > > From: Intel-wired-lan On Behalf > > Of Malathi > > Sent: Tuesday, August 11, 2026 7:08 AM > > To: Nguyen, Anthony L ; Kitszel, > > Przemyslaw > > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; > > kuba@kernel.org; pabeni@redhat.com; edumazet@google.com; > > andrew+netdev@lunn.ch; davem@davemloft.net; linux- > > kernel@vger.kernel.org; Malathi ; > > syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com > > Subject: [Intel-wired-lan] [PATCH net-next v2] e100: fix shift-out-of- > > bounds in e100_eeprom_load() > > > > e100_eeprom_load() and e100_eeprom_save() start with an address length > > of 8 and call e100_eeprom_read() to auto-detect the real EEPROM > > address length. e100_eeprom_read() adjusts the length with > > > > *addr_len -= (i - 16); > > > > based on when the EEPROM drives a dummy zero onto EEDO. A > > malfunctioning or emulated device that drives EEDO low too early makes > > (i - 16) exceed the current length, underflowing the u16 addr_len to a > > large value such as 65529. > > > > That value is then used as a shift count: > > > > nic->eeprom_wc = 1 << addr_len; > > > > which is undefined behaviour and additionally overflows the fixed-size > > nic->eeprom[256] cache. > > > > UBSAN: shift-out-of-bounds in > > drivers/net/ethernet/intel/e100.c:768:21 > > shift exponent 65529 is too large for 32-bit type 'int' > > > > The same corrupted addr_len is also fed back into e100_eeprom_read() > > for every subsequent word, where it is used as a shift count again: > > > > cmd_addr_data = ((op_read << *addr_len) | addr) << 16; > > > > so validating the length only once at the caller is not enough. > > > > Clamp the length in e100_eeprom_read() so the subtraction can never > > underflow the u16, and reject a zero or out-of-range length in > > e100_eeprom_load() and e100_eeprom_save() before using it. The EEPROM > > cache holds at most 256 words, so a valid address length is in [1, 8]. > > > > Reported-by: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb > > Signed-off-by: Malathi > > --- > > v2: > > - Drop the Fixes: tag and retarget to net-next; the underflow is only > > reachable with malfunctioning or emulated hardware, so this is a > > hardening change and not stable material. > > - Clamp addr_len inside e100_eeprom_read() so the auto-detect > > subtraction can never underflow the u16. The corrupted length was > > otherwise reused as a shift count for every subsequent word, so > > validating it only once at the callers (as in v1) was not enough. > > - Also reject a zero address length in e100_eeprom_load() and > > e100_eeprom_save(). > > > > drivers/net/ethernet/intel/e100.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/ethernet/intel/e100.c > > b/drivers/net/ethernet/intel/e100.c > > index 29960762e64a..26a7c0aaa6e2 100644 > > --- a/drivers/net/ethernet/intel/e100.c > > +++ b/drivers/net/ethernet/intel/e100.c > > @@ -744,7 +744,12 @@ static __le16 e100_eeprom_read(struct nic *nic, > > u16 *addr_len, u16 addr) > > * complete address. Use this to adjust addr_len. */ > > ctrl = ioread8(&nic->csr->eeprom_ctrl_lo); > > if (!(ctrl & eedo) && i > 16) { > > - *addr_len -= (i - 16); > > + u16 len = i - 16; > > + > > + if (len > *addr_len) > > + *addr_len = 0; > > + else > > + *addr_len -= len; > > i = 17; > > } > > > > @@ -765,6 +770,11 @@ static int e100_eeprom_load(struct nic *nic) > > > > /* Try reading with an 8-bit addr len to discover actual addr > > len */ > > e100_eeprom_read(nic, &addr_len, 0); > > + if (!addr_len || addr_len > 8) { > > + netif_err(nic, probe, nic->netdev, > > + "invalid EEPROM address length %u\n", > > addr_len); > > + return -EINVAL; > > + } > > nic->eeprom_wc = 1 << addr_len; > > > > for (addr = 0; addr < nic->eeprom_wc; addr++) { @@ -791,6 > > +801,11 @@ static int e100_eeprom_save(struct nic *nic, u16 start, u16 > > count) > > > > /* Try reading with an 8-bit addr len to discover actual addr > > len */ > > e100_eeprom_read(nic, &addr_len, 0); > > + if (!addr_len || addr_len > 8) { > > + netif_err(nic, probe, nic->netdev, > > + "invalid EEPROM address length %u\n", > > addr_len); > > + return -EINVAL; > > + } > > nic->eeprom_wc = 1 << addr_len; > > > > if (start + count >= nic->eeprom_wc) > > -- > > 2.43.0 > > Reviewed-by: Aleksandr Loktionov Hi Aleksandr Loktionov, could you please clarify something regarding this issue? I submitted this code as part of the bug report on July 7 v1[1] and July 10 v2 [2] and we were already discussing it. Later on July 10, the same code lines were submitted again by her. I noticed that her submission was reviewed, even though i had already shared the same code earlier. Could you please clarify why her submission was reviewed instead of the original one i submitted? I also sent you reply on v2 [2]. Could you please review that as well when you get a chance? I just want to understand how the submissions are being considered in this case and make sure the contribution timeline is clear. [1] https://lore.kernel.org/all/20260807145626.52692-1-pavankumaryalagada@gmail.com/T/ [2] https://lore.kernel.org/all/20260810083355.21631-1-pavankumaryalagada@gmail.com/T/ Thank you, Pavan