From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit 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=0 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=0 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=tail 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 == cur_rx`. But when `stmmac_rx()` is called when `dirty_rx != 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 == 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=221010 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/net/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 limit, u32 queue) dma_dir = page_pool_get_dma_dir(rx_q->page_pool); bufsz = DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE; - limit = min(priv->dma_conf.dma_rx_size - 1, (unsigned int)limit); + limit = min(priv->dma_conf.dma_rx_size - stmmac_rx_dirty(priv, queue) - 1, + (unsigned int)limit); if (netif_msg_rx_status(priv)) { void *rx_head; -- 2.52.0