From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 396993DCDBE for ; Tue, 26 May 2026 10:49:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779792580; cv=none; b=l4PDR1ztDSGsH9f0vWsZEiFP+U/sq6EV0+sT3eRahWo534AmcewcxHKhndJ4ndonPtuwDCV0GXpYaWc/aYw7FYGcrSoAexuyeMwDwXCxQrDSnkXREUCVtxEIA0iIo34wFS9daOv6Iqx1IzxmAk4AoVUSdEllOQoCcSvgs1Q1mN0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779792580; c=relaxed/simple; bh=JQ5BrlLA7NRE52ecTfeDwXHuvHRkEmiz2LzsJBj9lv8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dGtXRx3W008ihSJzQoRJ6dQixMZykTUSBKKP4A4bFKZT0WlMfYG1EMQjC8rhRSUmlcYFKD7QiNtS/7tA7+mNgN7DHct0V7mlrFH+LfmlxgWHYuqUDcCvwf0A9pVZPmGZLc362c7bbiiBrc2iJ9bszkFQHrCOoqTIoRCMCiopngw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZN0FtFXJ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=V8pQOHMv; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZN0FtFXJ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="V8pQOHMv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779792578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8Xb91WiXPazwge7GQc97YpLKCGyGlIds3mAgEY7YBag=; b=ZN0FtFXJ707EpvevpD4F4MVJFq3N1lpJQEJcE14r2LbZWsc+F5m31heDt40GZ2IjFtp5IO 5yQ+2iVZ64NOgLssFqRBb8UF5utS1eFgYuFbEkgFJ4+WsHEZt2oxM70atBBfuWIQpHfGuI P9Cyua7zJGNDr1I/nRIQt6IfbrWUbzE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-661-lKIQ26qXNw2d3g3cpVAcSA-1; Tue, 26 May 2026 06:49:36 -0400 X-MC-Unique: lKIQ26qXNw2d3g3cpVAcSA-1 X-Mimecast-MFC-AGG-ID: lKIQ26qXNw2d3g3cpVAcSA_1779792575 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-48fd64c32e8so70591995e9.3 for ; Tue, 26 May 2026 03:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779792575; x=1780397375; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8Xb91WiXPazwge7GQc97YpLKCGyGlIds3mAgEY7YBag=; b=V8pQOHMvGZvMPjcn8dU1zSLhridApTsW8NLudsCkBKUv4sycjzdiWk8m9ly1Lwq1wh EXr8hh0gwqCTntIy4sFULArqYMbOgEPuMmB9BOWirpgoaDZ1BZtQ0950qIHclUg/A2iH qAYM/8DPTjxaCBzf1FFbkix5yyy3efKVyNsfpUi8WXudTUDDyiOAtxeJBO2t1Y9pB/2X nqO1kI89mi30kK06azQar72rEb4E5u2yAzHmewQpLXWVdhE/IQ3Y8Ukzanr2HeSaLyWL ssOh/kpNmqGjHsP26ph2pDhN67FTYkRLW7N2mI2R/o7/YpfCvPO4YeiqCaZyN4YurQZi iO2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779792575; x=1780397375; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8Xb91WiXPazwge7GQc97YpLKCGyGlIds3mAgEY7YBag=; b=YsXSXVJ0A2M9UULncy9J3QO6ylrluljh2TijlpvhO37SzHxNddSbga8crfcfh1iiRl hUtnmA5hFID0YOmcNFR/Zbh9EKDiC8mFRfTcilLu1PIS55yIPMunDjWqKvpeZK9FYBJ7 g5KGceAJiNUtYmCoGD/SJSK8P3RD3/2VNilPqYSBWcvbOtkOldnKBrwmXLhTHm+MeOhT 3ffBkJw8WbA5o1mpBoSgV1F8MgkYWcPnjLRO6eNLWxUzi+mb0aTlmhoLHHw8i2lpLdp2 5NDbRElLnTTHuuMIntKt6VttpR81OlwyFSeB1Gq9ZRH12VieP6nGRzS1Gx61jdjrzyC3 hVHA== X-Forwarded-Encrypted: i=1; AFNElJ9dEvHls6/zh1TOI9xuMBCRUrGz3wWIKYB5GZgK2LMzU6+wPPom65dtlgN36OUQ6L3j9eN2dpIIxJTHyWE=@vger.kernel.org X-Gm-Message-State: AOJu0YyGXHz80Q1IPwjnr18DjVh2VgCnpIGQKkxg2X9wpI+nu6qkuKmZ UKJKeQ/CXl/+Sq5GX7BjlXTLA+PvpVmFD8aMxBFaOfXnYG78c2I+OQys59zQ7Wjs446c32m/KuT 8p7GKCQtmCrL/b4xadsrx6f+xGi9H5J7T2RQpKwIjLd2NReYLg0QJfd9zKGkwNETing== X-Gm-Gg: Acq92OHtWO+USj08aj/LIod4V4nHOP2sTjiWF36RVrglI8bm3e2US1xfEYg95nhfHY2 JGlRoeT37iN2QqJOosFPMvdOQhowrYaonr1ssaAJmA9WpVZjtJ6AHTYBrasrMdX8ga45Hxuyano ZYpEsu6jwGbC56wT/f9+noZKZ0rRhPsb7+vdPMNuIa2dPlWbd1wE/KfqQD/T1UyH6v3/bOLXybo oZEvu2BL7D+reKnXNSV4VtWzbgfYSnrXEkciCRUQoW7DzA4Mf+TDJ3ElEZd/zWk3fzNvDb/YR0U T0HdAJ2yW3n+/bWgfhCVSkJqUy7PGg0lPlJvYVYwrQ4mQmiI/PVc1LueRaWjiiy30hc+YFuiSyQ G4rH4R37Bin+YM67oDIF/2Bf3FlF6HpEm6XEd0u0UVoLjWBI6RyBV0OmLWQ== X-Received: by 2002:a05:600c:8b12:b0:490:5191:6e1a with SMTP id 5b1f17b1804b1-490519170d7mr255826055e9.24.1779792575171; Tue, 26 May 2026 03:49:35 -0700 (PDT) X-Received: by 2002:a05:600c:8b12:b0:490:5191:6e1a with SMTP id 5b1f17b1804b1-490519170d7mr255825705e9.24.1779792574774; Tue, 26 May 2026 03:49:34 -0700 (PDT) Received: from [192.168.88.32] ([212.105.155.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4904174a145sm148632185e9.0.2026.05.26.03.49.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 03:49:34 -0700 (PDT) Message-ID: Date: Tue, 26 May 2026 12:49:32 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] net: stmmac: fix RX DMA leak on TX alloc failure To: Abid Ali , devnull+dev.taqnialabs.gmail.com@kernel.org Cc: alexandre.torgue@foss.st.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, mcoquelin.stm32@gmail.com, netdev@vger.kernel.org References: <20260522-stmmac-rx-desc-cleanup-v2-1-76e78eb471e1@gmail.com> <20260523121708.564-1-dev.taqnialabs@gmail.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260523121708.564-1-dev.taqnialabs@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/23/26 2:17 PM, Abid Ali wrote: >> ret = alloc_dma_tx_desc_resources(priv, dma_conf); >> + if (ret) >> + free_dma_rx_desc_resources(priv, dma_conf); >> >> return ret; >> } > > The sashiko-gemini analysis [1] flagged two issues. > > 1) Double-free via XDP path: > > stmmac_xdp_set_prog() ignores the return of stmmac_xdp_open(), so > if alloc_dma_tx_desc_resources() fails inside that path, > rx_q->buf_pool and rx_q->dma_rx are freed for Rx queues. > > The interface stays UP, so a later stmmac_release() calls > free_dma_desc_resources() on the same freed pointers. > > Without this patch, the same failure path leaks RX resources > instead. Either way the root cause seems to be stmmac_xdp_set_prog() not > handling errors from stmmac_xdp_open(). > > The reported issue seems to be valid, but I'm not sure why XDP doesn't handle > a possible error in reinit in the first place. > > 2) NULL deref on partial queue alloc: > > If alloc_dma_rx_desc_resources() fails for queue N, > e.g. rx_q->page_pool = page_pool_create() fails, buf_pool is NULL. > The cleanup free_dma_rx_desc_resources() iterates through all > queues and will hit a NULL pointer deref in: > > static void stmmac_free_rx_buffer(struct stmmac_priv *priv, > struct stmmac_rx_queue *rx_q, > int i) > { > struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i]; > > The same could happen without the patch, and similar risk exists for > rx_q->buf_pool, rx_q->dma_rx, and rx_q->dma_erx which are all freed > without guards in __free_dma_rx_desc_resources(). > > I can add the necessary NULL guards in __free_dma_rx_desc_resources() > for V3 if necessary. My take is following: even if the sashiko reported issues are pre-existing, they are so strictly tied to this code path that it makes sense to address all of them together (different patches in the same series). Also all of the above looks like 'net' material, deserving fixes tag in each patch. /P