From nobody Mon Sep 28 23:06:24 2026 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 CED22390226 for ; Sat, 15 Aug 2026 19:54:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786823687; cv=none; b=Pqy+MakV0XhorteV0+GrAyDg0GDwS7n099CrsJ8YBQAL979RDS0X/7dIwDJ4I99T/41xRxgPsWqar99GRbeuXVYHY59UhbrVBWjP6utCosAHw1LmHgiADtnkRUQl14+CngTGfGBe3KrbCXOA29Xf2X6IcJewV9zPYVMDCvO6+5k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786823687; c=relaxed/simple; bh=kWTeXh3Svt4m5rvAE5ofGNUOjIyRiqMTYPld1Ha4ou4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=azhi2m/uYc5OifdgMrLC447zJIsdbbrsSTr/pdWCTEtM4awEHLUVdC4zpqXULdZY4rZ0xCUnOTMAQy91Qqu7GuKKrCXAYQEpgIvTgOpe4SmxQvcaiL73XW+LZkJGtOAU+c7WBBiwcWH60zr8ucA7yt/XlXwtILL1Q27d3HE67eU= 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=frGua4P3; arc=none smtp.client-ip=209.85.128.52 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="frGua4P3" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4956d1d9fb2so2950785e9.0 for ; Sat, 15 Aug 2026 12:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786823684; x=1787428484; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=D73r29eo7FuE38av/tnsBvaxMVdSvt5ucMGI01LSnOc=; b=frGua4P35OsTbtBcKGgTr0/TN+W/nDajrf/wlcyeJPRfQI2laAxjmp3BmQ2i1UI9+D yz2U9tt7bU7NZEWfNoPAKABxLvRjLwiBf0OTpus//sLfiJD91pJp+NodfFqf52xBI6wG PS96YKkBKLCQYU7vRdtmS/SVSfap4KHsqxE+83mu8z1DPoWshs1fvd4HbufHRciCDMd/ K4qjMLWBOm9HmOafLr+TDDHWb7/B7cWJPJaN+gwAmNxLP6Xpf2HnQbAk8RndUFjOsob0 /SCrqDOS1KvMTEf1yF2tbszp5wvoI93KywymKvl0SzUUCdBJL6sHfCmMjUGr0uzKY5q9 Bcag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786823684; x=1787428484; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to: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=D73r29eo7FuE38av/tnsBvaxMVdSvt5ucMGI01LSnOc=; b=kF6VAYSzFDha5TBTypo1e4hZcAjBeGjHpT7r9zzXVTxdVxVOe/NA2ViILwjbpJmUBN a84IiBM4aMd0Ig0t/AAB2Z68H7cqExP6Vlb+c6B4f8I8q04iEc4K44lmjL6Y9ckFERWj 19YGazPeGez18xSi5sAFJZ297pbBkXDclQzn71yurfH+bBQXJnk8RLWgkYwbTVI1+A5w 3Rd7G+YV9kQ7tSQTXZoaZOnhOiMz5V+HsmHto0qMmN83bRBuGWi6STC5cF+Y8QnQ4uDy RlTrpOVezltOxNUHOCikfEBlwedndFwxNv+bTB3a5JR7JghzycNDjBG8AO009HTM5Vrj N1PQ== X-Forwarded-Encrypted: i=1; AHgh+RrZhTHweXAZB+9hIh7+mYAzZ25wITwggTMpSzRKP1V2tr11VBL9SvIw0Tk2yPyw8z5tKxQWt0KbfJmWDP4=@vger.kernel.org X-Gm-Message-State: AOJu0YxXo1SLyjKx48ZH/+zzg52Jvel/hqdpuXB8mSwjpbm6XlmNfE9s 4XgAc7ylDYGZlGXcluvTZcd0PI1nqmbksPUeS2YvRPyn9S8B2Q09BTDX X-Gm-Gg: AR+sD13Q9QrNKCiO24A+/t58EOztkfjkly4Wvi8CLivefdNmNTWwNaQ70Lz/4XlsicA CDyGA7rt324erxdWOPhCio7YKdqYo8g+p0weLnHhgapRLvzw8d6fxg3skVzS4SYYCvuZOqD0TfH JIcms/uaVSCEy28+kK1LhLWuEFfK0GZH/Dv7olpBRVlJ9iP1MIt1Y9W6ZA68EWw8nifoelaJwpm 7QInEe58v51LX3lQJd1buzn3PQqIEA2K25Ztnh5k8IZ8UjzVnxDx3OK9zMMNslsXL8RX+nU73I9 cGtL2IfMkLA1CNcNn5YYtTir0BYn2JNqAENHsIri40/YMyI8Q2QdeubzVxy/NdbL4bghKYPnxoc eFtTmMKhMYGUcG4kiKN5lvvLtlI4J1WsqkcZCo6GmnbpRaezlQP/n5mrymnaILw5G+3RbQ3v1IE NzNvvqWE+C5XdWQeUKCofoQerByIo7/Vx2V1yisrpvBXw7WCngtg4tRL68EO7cuja0aZLp7QMS2 4d6FZZ4SIoq3QO/aWJbYpYxDMchxtmx1Gkp5VEwAg== X-Received: by 2002:a05:6000:402b:b0:481:3db3:8eb with SMTP id ffacd0b85a97d-4816072df98mr10085524f8f.1.1786823683911; Sat, 15 Aug 2026 12:54:43 -0700 (PDT) Received: from [127.0.0.1] (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f2c46besm18757609f8f.31.2026.08.15.12.54.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 12:54:42 -0700 (PDT) From: Marek Czernohous To: netdev@vger.kernel.org Cc: Rain River , Zhu Yanjun , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tobias Diedrich , linux-kernel@vger.kernel.org Subject: [PATCH net 1/2] forcedeth: fix off-by-one when saving/restoring non-PCI config space Date: Sat, 15 Aug 2026 21:54:38 +0200 Message-ID: <178682367885.3748309.10595890901761762683@gmail.com> X-Mailer: python-smtplib In-Reply-To: <178682367884.3748309.5288746298966501007@gmail.com> References: <178682367884.3748309.5288746298966501007@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Marek Czernohous nv_suspend() and nv_resume() walk the non-PCI configuration space with for (i =3D 0; i <=3D np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as u32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=3Dy turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: np->base =3D ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the "?" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth= .c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=3D, which saves and restores exactly register_size bytes. Fixes: 1a1ca86158ee ("[netdrvr] forcedeth: save/restore device configuratio= n space") Cc: stable@vger.kernel.org Signed-off-by: Marek Czernohous Assisted-by: Claude:claude-opus-5 Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun --- drivers/net/ethernet/nvidia/forcedeth.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet= /nvidia/forcedeth.c index 58d3e55def48..dc804e111564 100644 --- a/drivers/net/ethernet/nvidia/forcedeth.c +++ b/drivers/net/ethernet/nvidia/forcedeth.c @@ -6221,7 +6221,7 @@ static int nv_suspend(struct device *device) netif_device_detach(dev); =20 /* save non-pci configuration space */ - for (i =3D 0; i <=3D np->register_size/sizeof(u32); i++) + for (i =3D 0; i < np->register_size/sizeof(u32); i++) np->saved_config_space[i] =3D readl(base + i*sizeof(u32)); =20 return 0; @@ -6236,7 +6236,7 @@ static int nv_resume(struct device *device) int i, rc =3D 0; =20 /* restore non-pci configuration space */ - for (i =3D 0; i <=3D np->register_size/sizeof(u32); i++) + for (i =3D 0; i < np->register_size/sizeof(u32); i++) writel(np->saved_config_space[i], base+i*sizeof(u32)); =20 if (np->driver_data & DEV_NEED_MSI_FIX) --=20 2.54.0 From nobody Mon Sep 28 23:06:24 2026 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 C5293390224 for ; Sat, 15 Aug 2026 19:54:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786823690; cv=none; b=ExDiTs3aTt+6Vnpnrk4fWl6x5g5t2p5BvRNtKkcIlXRbek7MTmMkkurhl4RZdDk0Ff2sIFAn1YbJKM2HSWUwJMbkfvnwtGa6zTD2QeUuVbAmL3Munwux9Mx4+uaDil5K9E4FMDgHRsSzdcvC1S2EfPU4XrKQa9TU4pScrk4DWW8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786823690; c=relaxed/simple; bh=miYZtHBGCb0g+aO//LIJcOYPt0V4WopWlWDWAMp38PM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=VCqa9ihv+h5XTxPTNwFYRZOu48gUFrsbRQMLjzpFbH8lhSlUf0jp0JbovWxTkgdPusBI5Uy9tgv6JKBfx7L1h7uwic36ZCBvEbPWtjseKQ0EECMGTNK9nxO19X9NdNaxYX2lYDNMJpMT3kwV0hQqDEzciooR/fyhjJ8q8PYJ8zs= 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=lxhcxBai; arc=none smtp.client-ip=209.85.128.50 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="lxhcxBai" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4994d41ceb9so2957205e9.2 for ; Sat, 15 Aug 2026 12:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786823687; x=1787428487; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=OdMM+C33OrYXg8NL1f3naTX8b+0PfXP8Ol11Fi77gWE=; b=lxhcxBaiKQzmLR2Xutttic1WuK0v0mxfAiwXNHguWw7DkVp2+8oLsDE+/iuo5JnyZ0 WO1XzBNWZD+Z2LSNBVZtxqanZZXyTUK7Etd8v6V78r46bWuTQUHY6gL4st3lQWqfm00G 263RT7IR2nKpiozNz7CLfqpFHF+idncz9ipCSLc6Dn592Mp280swu2mGltw3dgP8/57a MM+BKslsFxunB4SN6WyT2XKrRPlVLCu/l2e/i22g+tjE3irMNmyzF9MkPyCLIk3UBdxg z6/YGZg7IRJetzd7Ev9ht3q5QqDUVb8wWcWZdietN2hBQ4l1UfL7el285EnszbB+lXof hVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786823687; x=1787428487; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to: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=OdMM+C33OrYXg8NL1f3naTX8b+0PfXP8Ol11Fi77gWE=; b=REAU3OtMsqEMbUS9PTbirWu6Y/adjEXtiVlV0fM+xCDItW0epkwz7f4Ybzgqxk8pda wsxUl/X/ZjbSmScAfqzuNduuOD6vzHHeO5XkKcSYj0uzrINHhgmZIOlqdRqbew1zN6Av O2i+VqjOxKIBbtYPkcGTSCMiUrw7eumeUeEWhmTCvl5S1rEBTdWpsidqlmHf+OY3j9Bu UzSkWCKdfRjPWnvdio7wv+vpFdVZWY7Hv4H0r/axlDJxStPjDbYZI9UCz6gYfwNdD8Ev EHF9KesypN+A6FrV5ptVE9mlMmYOWUnSNKRKLUnNGVGi9nuFzmBbCfGNj6RhLt3shNc2 j8Vg== X-Forwarded-Encrypted: i=1; AHgh+Rr7Bxo0HIRg7WmUqNaRkCYqIEJQtphtlSSiwrAgoKtJisq4BySgdCjLbbAt7i2XRoxzapnBq/dS0uAIEa4=@vger.kernel.org X-Gm-Message-State: AOJu0YweG5keSVlxeCVu5Sns42+kFXLPAKAwJl7r+ddl66XzIpx1zlRb KannCrZLNjSq5eQwSuKxbaXLMFX7bvjNrKjhEa5DYgRQrIdHhnowat3Q X-Gm-Gg: AR+sD11LJqbM+pn0k5WBQ1afZqt047XFRANSP5F8ozJ6vTYtUGBjafwU0QfdjBaVa7c 7v1bucdjWcl8JuEMRxUcXyHsWiqYpiJm9i7qxKRSzJD0MyRKbWwSz66TBdH7OauUPetsB7zGMw7 FWr1/2hLarU48qauQzgs6ckPKLv95AlW7uHoIyV6QaUJ4fWTrLVJ36ZJwjjqxAbVMlIJqL7amgA uatfiHTmYyyL4J6e7FuhhQVefuVydcFT2AFwzN8k63y18QCWT2V48F5tNoi62mjR4LobaeWYBek QvUz+9I1YHTqO9DcoXxSPcqXhtjjIM8HySBsiv3oSWg5+ZspaNlJG5FTXNafgpu3y4Ib7ELDyQ6 Xd0TI16hc14MIV5I9MBOapo3EsMLfLIKaAE5s6/lkBQwA12mVOlQe9MCJQ8WVWDOd/ZWtjYUU/Y tRR/XNOEkRAean05TyKG3j+3tqu6cLV0eeN28zTba4ALq/tpNN4egqFl6jRSjNaY9OimOMVj1TA rOh+BExUMj1+qcMu5sRaWuUOYXu3ivSCZdmHShMQw== X-Received: by 2002:a05:600c:8106:b0:495:4505:dad0 with SMTP id 5b1f17b1804b1-49987961eb8mr112534205e9.2.1786823686886; Sat, 15 Aug 2026 12:54:46 -0700 (PDT) Received: from [127.0.0.1] (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f2c46besm18757609f8f.31.2026.08.15.12.54.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 12:54:46 -0700 (PDT) From: Marek Czernohous To: netdev@vger.kernel.org Cc: Rain River , Zhu Yanjun , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tobias Diedrich , linux-kernel@vger.kernel.org Subject: [PATCH net 2/2] forcedeth: stop the tx_timeout register dump past the requested window Date: Sat, 15 Aug 2026 21:54:38 +0200 Message-ID: <178682367886.3748309.6978554332066826294@gmail.com> X-Mailer: python-smtplib In-Reply-To: <178682367884.3748309.5288746298966501007@gmail.com> References: <178682367884.3748309.5288746298966501007@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Marek Czernohous nv_tx_timeout() dumps the register window in rows of eight dwords: for (i =3D 0; i <=3D np->register_size; i +=3D 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base =3D ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <=3D register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >=3D register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <=3D to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous Assisted-by: Claude:claude-opus-5 Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun --- drivers/net/ethernet/nvidia/forcedeth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet= /nvidia/forcedeth.c index dc804e111564..f0218a0eab5c 100644 --- a/drivers/net/ethernet/nvidia/forcedeth.c +++ b/drivers/net/ethernet/nvidia/forcedeth.c @@ -2740,7 +2740,7 @@ static void nv_tx_timeout(struct net_device *dev, uns= igned int txqueue) =20 netdev_info(dev, "Ring at %lx\n", (unsigned long)np->ring_addr); netdev_info(dev, "Dumping tx registers\n"); - for (i =3D 0; i <=3D np->register_size; i +=3D 32) { + for (i =3D 0; i + 32 <=3D np->register_size; i +=3D 32) { netdev_info(dev, "%3x: %08x %08x %08x %08x " "%08x %08x %08x %08x\n", --=20 2.54.0