From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (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 756BF312825 for ; Tue, 11 Aug 2026 05:08:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786424904; cv=none; b=YRLCW7pCbt32FDgnZbuRnbpK7jXpz555pGKbCP6A8Do0e1TVQF79BAvnWl9y89A8LtZbEniWVYrR7B3KKoTuyLSMZU+fZrUasB2aCEQTFSAJPfA8z0IrBZYqhkouCIP09sjezUR9WGS6fqtkQb0udROSrIbFPeChDkahjGxYlCE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786424904; c=relaxed/simple; bh=20weYDl+VWdcv8t7mGQ/8FZanBnhDcVeN68+vHaqeUE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=cQfVHVMOpfizPPK/cUZlDuciisEHCRwFcda9g+i5jb+lnxc1Utdbwe62quPsU3Sfx3StJBhbeOn5sS7EEpyulInIJu18I5SWmv6RLqmIKA6b1Aum/I0EHmEuuzwLebtZwMQmeyUFVsLezvYvDkmy22dGG4pll+Lskht50RTmqWo= 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=cZh5w2K+; arc=none smtp.client-ip=209.85.216.51 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="cZh5w2K+" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-38deea72eebso2624370a91.1 for ; Mon, 10 Aug 2026 22:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786424903; x=1787029703; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=tZtc/eD52PoJvgCx24yZu3Y7VDOIu1uYZlUVL1bHOF0=; b=cZh5w2K+19vDguh/TqUwBtfcMSDkuuGOnM2bXfVFC/qxxgPKN3j2UjINYjbWHOzQU5 PbrnE4Im9okUcMAyH4Wq0piTqu08/kst3gr0LKSUT+JKn1fPmdEamWs+Qv18uObs3Tmk MS0xGiupXjBcUqP950YY0mbokKNx6hLN3WrVUk05OAuLYSb9KGoMJVnoyX/MTvpmztkX QZQRj3NM4fllWRN905sTpUFm5zVRG7rPtJtU+SzxK44SSLdRHSbO3O1y0UpwFcwST6m1 PO2CQhhD8fAbrnCTYXcu3F6VgtN239VPF3+bqtZv24PNk6PzpbUChFZuPtOhP+0BYacM DRrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786424903; x=1787029703; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tZtc/eD52PoJvgCx24yZu3Y7VDOIu1uYZlUVL1bHOF0=; b=fShToiX8ZEj40f/QPyz3yjv9kl8I13lUkg3FX3nZ0HAaujaYIxq9Z4oQDy9yhQQTOi SLOxjAafJMGyOuMxIBsRmPFUtW0lXVqr94tCXgeWC3d4320gZ5RIMlp42uxLz70EUOa2 tbIHSds1R4Z7AUFvPM+AVv7myNuDwiQ3W65qBvg1XT85/V+zh5QSO4xpwkQIqrxirOLU xxn65M8V8+uCfJBOA+D3Qe0Xd0lsaPtYqlaoVUIXYU6NM+P1FMkjhJzkaBt+mO5P5r+W R7vlPoE0eZd4ZC857Gcpwt8Oj9LNl3+8Qwly6b9nXXxMvswBCh79KJ2exaNixeBR0tbp HsjQ== X-Forwarded-Encrypted: i=1; AHgh+RqsX1lCDxJs2gUtpxnQGGmLyPQZXX1savl3qaNU/esCZUf5QN2orLp3CEjzJQzviII5TtCVNVHu5El07KA=@vger.kernel.org X-Gm-Message-State: AOJu0YzQiKMNesDLb6cDgpNZxjp96y6SY4yp7n5OY9r1029hs2mKBJoH njPhytZoaJiHZ3GSeqZCfPDvYwZukJNZerHNHDouZhrdlGNRkn4yGSG2 X-Gm-Gg: AR+sD13Jp3ecTZ9dpz72HH7ujZ4Y1vsjtzCmg7k0zDdqIUWawW1BEmxLl4tTzz6zyEO QhJA5E6ydMuGrMBkzwREQwl+Y8eFAwwJTLMLoaWIKz3Iut6SXPCBCNpWPU3exceZGm/GjdrM+tu srHp5QDA3Djba5XfHUdEmpfc1dOFBySty3g7LO0jzg+p9WW+LXOTguOmYgQwB8BtAAyUELHoVC8 AWwReaD4+BuBLn7938lLa13QFGzH3NhbehsdgMHEoukQ1V7uDZKADOiEzytPRkg8fUjlxRAY+lz tFqm7Bo4bhiL5UtaodFu0A4eLsKD3hGiW4/e/jE/MgJfuEC1tmUE1YO5w4skuLA7OS6Rqbd3b56 VqhKQnJpdYzQ+CW4vKe8yyPLgNRixfQyXz3tTD+ri1+vGmCfXlCDUzMsiNrdM4VKiNIkki6T60/ XjkNlxHEqj+5kszDU6DlUsy/MoWUwtA3FT3sRMUn6G9G8tIJB5b2E68KDkYaLFWyi+0WZrx2ent yNWmd2AxQMz6BBZ90fsVfWD6Q+Tnrtq9SQtGQ== X-Received: by 2002:a17:90b:3c84:b0:38e:9045:babe with SMTP id 98e67ed59e1d1-392ec5068a1mr800863a91.7.1786424902737; Mon, 10 Aug 2026 22:08:22 -0700 (PDT) Received: from amd.ban-spse ([165.204.217.251]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14120443418sm1389450c88.12.2026.08.10.22.08.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 22:08:22 -0700 (PDT) From: Malathi To: anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com 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: [PATCH net-next v2] e100: fix shift-out-of-bounds in e100_eeprom_load() Date: Tue, 11 Aug 2026 05:07:53 +0000 Message-ID: <20260811050753.234931-1-malathi.a2000@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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