From nobody Tue Apr 7 04:58:33 2026 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 8CB0230C359 for ; Mon, 16 Mar 2026 02:10:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773627033; cv=none; b=Oi9pCojkk/c81lcFuuAG46MMVItSsNMMMLeijhSn0yxjrzTH6TPQfztn1wpdMRRQ+q5gERflZ+ofnNTMDx6MmB4eyyE4Y2mECTBSr3e1T8QfsxNdo7HR2+2L5gUZF+zus82jogfJOIHUOButffCuqI9ur0GrDZp0mj5m/NCaSY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773627033; c=relaxed/simple; bh=iodMKVlN3gtM/vH3ohWtM82lJdYH0tG9s5iJw5Eun+Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=epPokaXdcXfTrpcBAYoPkwz4OJw0Le+Svkk5bIR5iOwA8gib9sWGPKuAAuNJBHR2kuMl1McBghH4b7n0BvkWEEixK8eodCd9X6zszgwlKvIYUQBGykuxia5YWgzykvcp3B770ucCrEPOogYJXH0dJ0lwerInN3P4oW1S5OH6WQo= 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=Xv2j3yDX; arc=none smtp.client-ip=209.85.216.45 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="Xv2j3yDX" Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-35b85613f3fso1271758a91.1 for ; Sun, 15 Mar 2026 19:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773627030; x=1774231830; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=C/yM1cLEJPCynSBddhLco3TyOcjIuEN7QpwgVXpMHAA=; b=Xv2j3yDXPrTyQuKX6iVJLFpC/pbzRiea5pzNyB/N9KweAf8h0yLbSczOmuSqV4oBhZ jsDOTdizRgsguE1UWBTVRrDnq337v1QHbdAGWYQb1lxR7lNYp6FYq5NoHGy+mD1pJWE2 OCRbss6yT4VIz/gN8qzYiZH9wE6oFOBlnhR1/583824fC4b833c2CVnVTLyLc9EsgqqJ 3zGjruGBaSKX8WPTi6urORsysjEkEPoXwehdg2TgX43sLumyVoXEb/Fq0yFcHLzXk/7K FpS1QRfLoTMoGUadggyxbsWrPFO+gLOGjFIRymhNywWPjoOtuU+w4aNLJqOk+EeIYBUD L4PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773627030; x=1774231830; h=content-transfer-encoding:mime-version: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; bh=C/yM1cLEJPCynSBddhLco3TyOcjIuEN7QpwgVXpMHAA=; b=F25FlTiKUdc0X47WjkjZ6BePvncvzCpK67VLf75JndBzkKIEqjoHcALJIq7Ssh+XTq 8L8HCnOFyeDdopWsSiJuMo5xpV/5Ubqf9tsguplbhO0j/HJt77gTt2sn2/XA4Vqs9MzZ LZLez12bf9ygxVzOf+INP68DEBCb6j2h1zoUuzqNgCuP2ldPA7OOa3eZEXCHNfAEd5rZ aSo7GDrbaBoCi99n+CjDi/xV8OrgHlXYHJqHN5FDP4dTm/AeR69Kp7TuHDzZOoWbvbMA NSZLEkhqTj14TQKbvobU44AxU1BiWe+U8ogMfDYA3VybV5HPM4R1DR/l+5ell+Yqjuwq ma4w== X-Forwarded-Encrypted: i=1; AJvYcCU1nJPDDpa/XxskFqoOQC8RrzPpinyCikspZcEWee3GLqAFPS5J6Nyd2r2KlNnnbt9lArULhiPEPF1sm94=@vger.kernel.org X-Gm-Message-State: AOJu0YwbF9X7oHt8LC90v9C//Mj5n8x1P9itZtsglrlRNh8kMC8YEmZr 2+akXz+rsVZSpt+WEFjFM+cejAkKLyps+UgVq01QPm8Z9pnCH2glLScq X-Gm-Gg: ATEYQzyExACF8F+FdoasYGfN6r4l5eS87aqOCQZVoLGQsLqFh00tRCxOYb1Pt5vxe7S qzjsUA6B1Z28S3EyOIkLosbRDkxHgzCVJsv1aJztQY+xW4rjehn9uRAjJ2Y9qQZtx5ecGh4R3lq hlv2PENpVPWHGBugsLG5s7aNK7qfdC1tk8tuinlMhiWrAm9PC5PTkkenGwiUEEGu7+y3rO9rjJh Kz72WG0OuO085aOtEs9vS7oQ/fiCnreJHv5JZ3Xge5ue3PdYewSFEjyWLEZyNAFciriiOnECAc+ ZfaZAc+W7vyGXY/hcqvIKh226NT+FNn3xdNX7yM0mWpf7exZ6DWED/W12fEBFMIhBRzEOotMztU VrclzV/aSISpqmYB08WqSQBbvahFTId28TkMJpYmWg+6qqTQnJX2g0PKkyxFUT960d8qtX31sLK ANWt50h0ywT3X9q+ngXiFlVGaH735Hvxufv8lsSdUv60ng2ncZ20GhdWE/mHCj3D29 X-Received: by 2002:a17:90b:4ace:b0:359:f8c3:dada with SMTP id 98e67ed59e1d1-35a21eb5ea6mr10794612a91.13.1773627029885; Sun, 15 Mar 2026 19:10:29 -0700 (PDT) Received: from luna.turtle.lan (static-23-234-93-211.cust.tzulo.com. [23.234.93.211]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35a02ffdfb7sm17705805a91.14.2026.03.15.19.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 19:10:28 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Russell King , Maxime Chevallier , Ovidiu Panait , Vladimir Oltean , Baruch Siach , Serge Semin , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sam Edwards , stable@vger.kernel.org Subject: [PATCH 1/3] net: stmmac: Fix NULL deref when RX encounters a dirty descriptor Date: Sun, 15 Mar 2026 19:10:07 -0700 Message-ID: <20260316021009.262358-2-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260316021009.262358-1-CFSworks@gmail.com> References: <20260316021009.262358-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Under typical conditions, `stmmac_rx_refill()` rearms every descriptor in the RX ring. However, if it fails to allocate memory, it will stop early and try again the next time it's called. In this situation, it (correctly) leaves OWN=3D0 because the hardware is not yet allowed to reclaim the descriptor. `stmmac_rx()`, however, does not anticipate this scenario: it assumes `cur_rx` always points to a valid descriptor, and that OWN=3D0 means the buffer is ready for the driver. A `min()` clamp at the start prevents `cur_rx` from wrapping all the way around the buffer (see Fixes:), apparently intended to prevent the "head=3Dtail ambiguity problem" from breaking `stmmac_rx_refill()`. But this safeguard is incomplete because the threshold to stay behind is actually `dirty_rx`, not `cur_rx`. It works most of the time only by coincidence: `stmmac_rx_refill()` usually succeeds often enough that it leaves `dirty_rx =3D=3D cur_rx`. But when `stmmac_rx()` is called when `dirty_rx !=3D cur_rx` and the NAPI budget is high, `cur_rx` can advance to a still-dirty descriptor, violating the invariant and triggering a panic when the driver attempts to access a missing buffer. This can easily be fixed by subtracting `stmmac_rx_dirty()` from the clamp. Because that function currently interprets `dirty_rx =3D=3D cur_rx` to mean "none dirty," its maximum return value is `dma_rx_size - 1`, so doing this carries no risk of underflow, though does (like the Fixes:) leave a clean buffer unreachable. Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D221010 Cc: stable@vger.kernel.org Signed-off-by: Sam Edwards --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index 6827c99bde8c..f98b070073c0 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5609,7 +5609,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int li= mit, u32 queue) =20 dma_dir =3D page_pool_get_dma_dir(rx_q->page_pool); bufsz =3D DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE; - limit =3D min(priv->dma_conf.dma_rx_size - 1, (unsigned int)limit); + limit =3D min(priv->dma_conf.dma_rx_size - stmmac_rx_dirty(priv, queue) -= 1, + (unsigned int)limit); =20 if (netif_msg_rx_status(priv)) { void *rx_head; --=20 2.52.0 From nobody Tue Apr 7 04:58:33 2026 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (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 9EC5530BF4F for ; Mon, 16 Mar 2026 02:10:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773627034; cv=none; b=aMN2ZwxU9YlgEq3VUzUhG5FxTh5sUkhYwr32SBAnOVHyRZW3A2+jgvOPrXaDtSk64KA8OMMB7h0KxKJWN8xSWSw+QI/7dRHCTS5P/HxSO2q+bT28Ih+ZFPqFH5uO5EhyQ/uSoCu+hfbv3uQ2ZSZM1KjCOhXDG4rsJ8xCot86lEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773627034; c=relaxed/simple; bh=NA2WPiExcFM1F1Er32slS17NHJTG/FN7y2tKTlUTUQY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TvEeKzet3JDTMhR00kjx51YAIksfktFJ7DuPWwJ6xa5zXgVYSiXcyHhkNLtFnKBxR4ek6i1w+Lym2s3y9GB/xRVb43cn9rjKMyh1h3feV4+blbeo1opKukQ/Hhd65niQWMZ3aQdvPj1dc1ye58nz+3M/ZjehSYIIaWp7gv7vZIg= 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=Z2H5CHbS; arc=none smtp.client-ip=209.85.216.46 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="Z2H5CHbS" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-35a04d6aeb0so2423979a91.0 for ; Sun, 15 Mar 2026 19:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773627032; x=1774231832; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MWF2mf3kVPfppDp36uMCmkCxPdxULYmBpYhT7oMPfhU=; b=Z2H5CHbSvuUUU83B+YJHt2zwIY6rc1/234OnVbjP4bZmN++uY4F82faoDfiHw2BcX9 AVdmjS+TlE53AJywca+pJvv7dXH1SDsN/IDr3LX3ax1SOEf/jgI6nmy17x0s512qiviG dcTAp2Cb32xQiPrq6A35/Me+BPZBOwIV4oRNfkpSPtV56+02IuJ7M7JpClv1IKs/yQWB 8xwC+qP+CGbJjHvxmfrzIzzKYzecIp3DztuBxfubrxvlb8B4qgbx9KCHURhdnkSnQU1X LuUzWezNF2UN3U+nLUAyoB8E6ZH67IK1MPCh1Q8H0xPXSf8r+vf+DvYI+IiHDoYNlIAQ 5pjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773627032; x=1774231832; h=content-transfer-encoding:mime-version: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; bh=MWF2mf3kVPfppDp36uMCmkCxPdxULYmBpYhT7oMPfhU=; b=mZCIHyfIBs0MOGy10cLXYnkpdM5Xs74Hny6J4y4t2kF6q/MPtrJXKgV+j4v/lb4U4f DyKmh+PfGXAYjO6GN6YUmPx5VUaeNwS8bjuF9M5+8YrObB36YDzx0S84MNm9TObzbYdT 1eUcI75uv+UzHFThFir/rDHw0hYQhCftYsOs4SK5c+3PYl415fmm02JvqZXBpkmoMuGe vhe8hI6U6peZsH0JW+bgoyKM3lAOhuCmD9Cj/3Lis4kfwm1vpS8gsEss/qEyZcvBphJz K0/CRYXM6UgEbGy3k/JIK2/5ko6gj630PcVZP6hvgkLZXERcOYRXGjVklYhNFgme9Jei dj0Q== X-Forwarded-Encrypted: i=1; AJvYcCUGQ4obD/wpttb6mtpbnpmJO95aw0QxNEviDDb2Dx6zo1hLMLlbripBaMTFY2rH5ky0pKGVtfIWBAN+M8o=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4zNPCwVdFyefLJ28uFF4hwRPKMGS/7EheznLU7J5I98JCigMb J8WOSjIlTobcqSyARMHyrNOoCeGtNQPQ6yPlFAFTcv1nh9pFZhxg9B2m X-Gm-Gg: ATEYQzyRjPbur/A5hIpvVk5Pbi3j5qTkvtfuBemvOqZrw9rJW1bTj8lFE5j5WjNJwgm yO7CfinVV6s4ASaHO2j3dFv+p4utDtdkdhNku/553HUL5RmFub6hcugQI4a8ln+MMoyJwPjwWKq djw3BO/buhAmetfXX7oMxz17b+OaDBmZflzDfEKUyyYMX70FFHpXlLtVkzPljam37qW1v0YC9HG sX/lCxkcxSnrhLIsRWWeZwisG3h+PVjAYvDJWiWsoQjReizgUk81RHH13JAEsa1twz7aGyl3iTL zV+Wbb6YNhUPHQ5iH8BLOS1zjObfDx+UCoeVW6GPk150WmtC0TqdZXxnOKVrTxOdkuhbpbsslrC ac8oO6lG+ygb7wV+FbGSooJmMNLI6oT2q3VGYC0FAyJwQfh5SI0vVvpfgoq/1GnqqPH3iu+Jba9 w3HTSf1dUdK879r/L7eLgghILRa+v2EBlJGgfahg6aHqTlmsgj1S1vv0n/i3LAMeW/ X-Received: by 2002:a17:90b:3501:b0:359:fa1e:2bc3 with SMTP id 98e67ed59e1d1-35a21ea5dbfmr10103044a91.6.1773627031911; Sun, 15 Mar 2026 19:10:31 -0700 (PDT) Received: from luna.turtle.lan (static-23-234-93-211.cust.tzulo.com. [23.234.93.211]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35a02ffdfb7sm17705805a91.14.2026.03.15.19.10.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 19:10:31 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Russell King , Maxime Chevallier , Ovidiu Panait , Vladimir Oltean , Baruch Siach , Serge Semin , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sam Edwards , stable@vger.kernel.org Subject: [PATCH 2/3] net: stmmac: Prevent indefinite RX stall on buffer exhaustion Date: Sun, 15 Mar 2026 19:10:08 -0700 Message-ID: <20260316021009.262358-3-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260316021009.262358-1-CFSworks@gmail.com> References: <20260316021009.262358-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The stmmac driver handles interrupts in the usual NAPI way: an interrupt arrives, the NAPI instance is scheduled and interrupts are masked, and the actual work occurs in the NAPI polling function. Once no further work remains, interrupts are unmasked and the NAPI instance is put to sleep to await a future interrupt. In the receive case, the MAC only sends the interrupt when a DMA operation completes; thus the driver must make sure a usable RX DMA descriptor exists before expecting a future interrupt. The main receive loop in stmmac_rx() exits under one of 3 conditions: 1) It encounters a DMA descriptor with OWN=3D1, indicating that no further pending data exists. The MAC will use this descriptor for the next RX DMA operation, so the driver can expect a future interrupt. 2) It exhausts the NAPI budget. In this case, the driver doesn't know whether the MAC has any usable DMA descriptors. But when the driver consumes its full budget, that signals NAPI to keep polling, so the question is moot. 3) It runs out of (non-dirty) descriptors in the RX ring. In this case, the MAC will only have a usable descriptor if stmmac_rx_refill() succeeds (at least partially). Currently, stmmac_rx() lacks any check against scenario #3 and stmmac_rx_refill() failing: it will stop NAPI polling and unmask interrupts to await an interrupt that will never arrive, stalling the receive pipeline indefinitely. Fix this by checking if stmmac_rx_dirty() returns its maximal value, returning the full budget (which tells NAPI to keep polling) if so. Cc: stable@vger.kernel.org Signed-off-by: Sam Edwards --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index f98b070073c0..d18ee145f5ca 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5593,6 +5593,7 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int= limit, u32 queue) */ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) { + int budget =3D limit; u32 rx_errors =3D 0, rx_dropped =3D 0, rx_bytes =3D 0, rx_packets =3D 0; struct stmmac_rxq_stats *rxq_stats =3D &priv->xstats.rxq_stats[queue]; struct stmmac_rx_queue *rx_q =3D &priv->dma_conf.rx_queue[queue]; @@ -5870,6 +5871,12 @@ static int stmmac_rx(struct stmmac_priv *priv, int l= imit, u32 queue) priv->xstats.rx_dropped +=3D rx_dropped; priv->xstats.rx_errors +=3D rx_errors; =20 + /* If the RX queue is completely dirty, we can't expect a future + * interrupt; tell NAPI to keep polling. + */ + if (unlikely(stmmac_rx_dirty(priv, queue) =3D=3D priv->dma_conf.dma_rx_si= ze - 1)) + return budget; + return count; } =20 --=20 2.52.0 From nobody Tue Apr 7 04:58:33 2026 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 6944A309EF9 for ; Mon, 16 Mar 2026 02:10:34 +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=1773627035; cv=none; b=YUU9ydWKas4rYChtPEsBUaufl6Knm43ANK3YckC+/HOkgLlgOInOqCHYQDlTHwEMikmDwgchZ8kpUmX0jtqFmlhUEMt0DnMwPiZtXu0m9X6YQ4wf0tvcIVpWzbaaZ3hP5w7JCEW9YAWI7WYHZHSWyaZ/WU2qFi+5ErMAs57ndIo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773627035; c=relaxed/simple; bh=LXy9mgSk9KFtLnI78bQHx+dwMcHJQ3vb3A/OuiACBE8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JUJXn41+GkN4BhuFLhOkO2w4+8gnl+/+6QKB8jn4nVF3oMY9CpCnHO3W1gfxj7WZzDJsk5VFN+XSAV4r55X1kQ+LYm8YI2A3pV43Fq6BMtu+NkkbRymJWm3Go0Na1a+rRiOP820C/SUAiPwLA4aABiEKdVp4DXfwMMNCYNegZpg= 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=LxYr+wfZ; 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="LxYr+wfZ" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-35b95a7444bso500372a91.1 for ; Sun, 15 Mar 2026 19:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773627034; x=1774231834; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5cK4DSgf4/rvokOqdV9NzEntXk8odHo4nT46mIGyGv8=; b=LxYr+wfZAbDNee7BG1gvD2vI1PiYYgz8CRCNH7FrL7a9T6mgwLljcEgLbCjA85w0mL KKU7Lx7YHN5PqEiThCRNWC1vyodOLT1rR5XWe+01nwPbN0lLosX6TGedREr7H70MNMoP RyDVp/91HjyvJhhhxy2QYmlTjqRn1eEGjlxDioEl4YIUnd96CZNsupZOB6cEb8JQ54hP gBAFWdNj+eh6Oz1EKHqpsMpscBXHDVbQuRND6S9YskvtXtCNlOG6H2FgpYqH8YCIglfU i2fsj9Usb9RAqrkC+70gKLo1eObBn75pkUKndqhnvOwp8xgsICqXrr+EgGSNlgn/koAP 5zIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773627034; x=1774231834; h=content-transfer-encoding:mime-version: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; bh=5cK4DSgf4/rvokOqdV9NzEntXk8odHo4nT46mIGyGv8=; b=In0n71Bmx6ojWIsM2dH6uYKMvsDjKSXXtLhAVOl9CNdtQQJmHU8QR4dhAd1Omp2hxp oMbcRg5ZbFBUHK1+7zxoYwYpYTNlkvKetPI4PhvGfDZl33XOn184Jdmz8yjzVt36WrD8 E+8gSue+ugBcwigSiRcBwDuX9g1UBUKH1vI4JTfK+Pre6RlTl5fOzou2445E8/jGCCkn q+voc7fZdhTxEGey6dpIafO1vQ1CURZAI/vNGCUDQAtSmoPOXuKgRpJ6nxRCXQr4BKKj Q5VniCRFlhZQMP1ohwMAkHzSD1qu0Gl/JNExfT5ExtYSQYP5dwOTYWLmdhU8MwDMExtq juQw== X-Forwarded-Encrypted: i=1; AJvYcCUEHkRIEdFeAoTzaeLHwxOvlJoStABGsHOCbkHFvMbbGYh3XrlL4ptZwX2Zs7P+NisGECV314yO7An6dOI=@vger.kernel.org X-Gm-Message-State: AOJu0YzeP2rnj/r2z9y8uhZ+c+klOVMtOD6jgn1sBjz9XmDGH+tBXvDc LxhYgEvnaTjIBU9QgzJLqScE3LojLL/4hciAHqVFOFF6+uUdPcdTDYPx X-Gm-Gg: ATEYQzxsSovv5rO4BQarB+BdyXm1VtiDLWdniDd+phmEmtd7Cp2SZnHZ5wJ49vYkii8 bR8wwVa++QFYo6/26jPjkObA2ObU8JbzzNl0maKoZo0JryVMf6hjl3ovnNEF4tnMeyW3HPINRYF wSsZSskhVDwL7ubAyU0ezdw6hnbGf1ZCORh/fj33gk0eCdL6nSkHXNwNJq7cMmU73ApBDuTtRLn gwQ6K1p56lQrQ8eHDFap+ZPAIMSByOoLqArUTD0cdM0JEDir+mvpkjr0Fgp3ajboj/icODRZwse rmwsoIjzjOBj6LcPgLfPlHPbsDvkPW24y0SrQvIG8qqVllgxvvyOB38TWF9dffVPKMbtvSrj459 C1yuZGKgnDKOlJUDKXFXq//GBkE64A+wjd8ipZ82FChaPOHiKnbsZPz76bVpjsmtOGFh/rEHFAk i17ZEhojHF6cHdK2FDThs12/1idmMeX5P7mpBcJBOlanf1pQIMgm8L8LRxQBtAEIwU X-Received: by 2002:a17:90b:4ccf:b0:336:b60f:3936 with SMTP id 98e67ed59e1d1-35a21ebca88mr9426301a91.12.1773627033840; Sun, 15 Mar 2026 19:10:33 -0700 (PDT) Received: from luna.turtle.lan (static-23-234-93-211.cust.tzulo.com. [23.234.93.211]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35a02ffdfb7sm17705805a91.14.2026.03.15.19.10.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 19:10:33 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Russell King , Maxime Chevallier , Ovidiu Panait , Vladimir Oltean , Baruch Siach , Serge Semin , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sam Edwards Subject: [PATCH 3/3] net: stmmac: Remove stmmac_rx()'s `limit`, check desc validity instead Date: Sun, 15 Mar 2026 19:10:09 -0700 Message-ID: <20260316021009.262358-4-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260316021009.262358-1-CFSworks@gmail.com> References: <20260316021009.262358-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A previous patch ("net: stmmac: Fix NULL deref when RX encounters a dirty descriptor") fixed a bug where the receive loop may advance to a still-dirty descriptor (i.e. one with OWN=3D0 but its buffer(s) removed+NULLed), causing a panic. That fix worked by tightening the loop's iteration limit so that it must stop short of the last non-dirty descriptor in the ring. This works, and is minimal enough for stable, but isn't an overall clean approach: it deliberately ignores a (potentially-ready) descriptor, and is avoiding the real issue -- that both "dirty" and "ready" descriptors are OWN=3D0, and the loop doesn't understand the ambiguity. Thus, strengthen the loop by explicitly checking whether the page(s) are allocated for each descriptor, disambiguating "ready" pages from "dirty" ones. Next, because `cur_rx` is now allowed to advance to a dirty page, also remove the clamp from the beginning of stmmac_rx(). Finally, resolve the "head =3D=3D tail ring buffer ambiguity" problem this creates in stmmac_rx_dirty() by explicitly checking if `cur_rx` is missing its buffer(s). Note that this changes the valid range of stmmac_rx_dirty()'s return value from `0 <=3D x < dma_rx_size` to `0 <=3D x <=3D dma_rx_size`. Signed-off-by: Sam Edwards --- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index d18ee145f5ca..9074668db8be 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -375,8 +375,11 @@ static inline u32 stmmac_rx_dirty(struct stmmac_priv *= priv, u32 queue) { struct stmmac_rx_queue *rx_q =3D &priv->dma_conf.rx_queue[queue]; u32 dirty; + struct stmmac_rx_buffer *buf =3D &rx_q->buf_pool[rx_q->cur_rx]; =20 - if (rx_q->dirty_rx <=3D rx_q->cur_rx) + if (!buf->page || (priv->sph_active && !buf->sec_page)) + dirty =3D priv->dma_conf.dma_rx_size; + else if (rx_q->dirty_rx <=3D rx_q->cur_rx) dirty =3D rx_q->cur_rx - rx_q->dirty_rx; else dirty =3D priv->dma_conf.dma_rx_size - rx_q->dirty_rx + rx_q->cur_rx; @@ -5593,7 +5596,6 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int= limit, u32 queue) */ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) { - int budget =3D limit; u32 rx_errors =3D 0, rx_dropped =3D 0, rx_bytes =3D 0, rx_packets =3D 0; struct stmmac_rxq_stats *rxq_stats =3D &priv->xstats.rxq_stats[queue]; struct stmmac_rx_queue *rx_q =3D &priv->dma_conf.rx_queue[queue]; @@ -5610,8 +5612,6 @@ static int stmmac_rx(struct stmmac_priv *priv, int li= mit, u32 queue) =20 dma_dir =3D page_pool_get_dma_dir(rx_q->page_pool); bufsz =3D DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE; - limit =3D min(priv->dma_conf.dma_rx_size - stmmac_rx_dirty(priv, queue) -= 1, - (unsigned int)limit); =20 if (netif_msg_rx_status(priv)) { void *rx_head; @@ -5656,6 +5656,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int l= imit, u32 queue) entry =3D next_entry; buf =3D &rx_q->buf_pool[entry]; =20 + /* don't eat our own tail */ + if (unlikely(!buf->page || (priv->sph_active && !buf->sec_page))) + break; + if (priv->extend_desc) p =3D (struct dma_desc *)(rx_q->dma_erx + entry); else @@ -5874,8 +5878,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int li= mit, u32 queue) /* If the RX queue is completely dirty, we can't expect a future * interrupt; tell NAPI to keep polling. */ - if (unlikely(stmmac_rx_dirty(priv, queue) =3D=3D priv->dma_conf.dma_rx_si= ze - 1)) - return budget; + if (unlikely(stmmac_rx_dirty(priv, queue) =3D=3D priv->dma_conf.dma_rx_si= ze)) + return limit; =20 return count; } --=20 2.52.0