From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (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 B802E436342 for ; Fri, 29 May 2026 18:45:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780080306; cv=none; b=XLbeRbxu9ZghSBj3LN1IzVhOYraqTjoCMsCmXuXKgs9uZRpa+QRhf6txtxjmM91DjOYZFtnkw5/blr9C8bzdp0awnZbDq0GuiKnd+9TQR7kj6/LhcskxZatXuUQbefBGXzMNiCvYY7RiavRMWMC/ta0M7qhyHdNCCdIZu1StRd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780080306; c=relaxed/simple; bh=KjM2Ni9kLOHksR3CwYDNLPuEOsZhbAgj/KuRPDe1DyE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TFdyCFoFcNKqd5F8kXqoF0aR47cNLlijAXUHOEuiGQ1B60kPsqjYAr7O+7wCcSDoD7jiRBl2DF2Bf0zEmO9K7QalnVJ1RBN5F3zOKMpihV+KI/yrDbRKZL+UJ6yXPxcOkLKQXV1OZCQ3FJ6aBEo0GvmTm5rPRh1D76iW/r8D9XI= 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=qygqTzKe; arc=none smtp.client-ip=209.85.216.53 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="qygqTzKe" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-36ba706ab46so1021509a91.1 for ; Fri, 29 May 2026 11:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780080303; x=1780685103; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IPBlF0ar3Vo0BpTSWk0IeaLhPGiCMkKemPuV249ODbs=; b=qygqTzKefO8YPcA6jt+4JU4EjuaGvOED/45Um/TXi2sWp0zJqc2ktNlyfhKsixr8jN WPQVQFLHKNYer3cOHecZ6IT6JoukfhVBcjdxSAxvxu6GjpBWFt05sw0A+kc74XJRJ9tf DN8AXKJ8FNDG79gbc3Rk3AsnCH/imkxef/X4pM5mrTBcdG2RnnrVhEAWfl20LueK2QNK seQ2dZy3Vjl8wOvwWGCIYQlej1Vp1ag2sWP/1bQyTi/nLbG4a5nR0ovuvqiQ22oeEmA2 8lXBmIeo3D/IcJaZQRZgFw8645Tum/AqMR6DMLs3gGCLN3M43t4jDUPwc+1M8nosMn97 vRuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780080303; x=1780685103; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IPBlF0ar3Vo0BpTSWk0IeaLhPGiCMkKemPuV249ODbs=; b=N6Ln2Vl/Rf/4TWR1TMVEdvmT1Qe1hdHZaxkR6kbEa+nWa2VAF/yMoBRsI3QLqTTHdx 6oxICLYaVPGQVvplJFBopmxjyT22W7PNprZ3SqWKXVhsXhAj6LHPsElks5AIvjv6YPmv N8hy7a+OZXm9sXtt3D1ScHBzIVQjLeoS+FothlCD+4imbBaGafDx5glVMlb2EHzZTSQz K7gyN82CpckxQjQ+NowIQ1FcJDMmiCCEFlE7yTuDi9qnKSpqMkG1S+CGgdrHMeT43n+m QG604c542HZlHPnlFvsd7WdRNddTI90BoeCTr8GWy2Il769its3uJA1dMZ/lqbryRkiE jnmQ== X-Forwarded-Encrypted: i=1; AFNElJ/xBbAx3Z/BcJiZu9ss3BiUVabScc2M0L9tTHhsslIrd0nhGY0QBHNcqDZpNZERlMX8D/dCLfUDFSwmwd0=@vger.kernel.org X-Gm-Message-State: AOJu0Yzh5e7b8ZjeEMfR7ZPrLTfk2rz9X3OBSNh3J03eaKD1qD3uePqX PcIokk6EKNO8MmVSKTpa06EfTL6FQ0zI2WXvJhSId8h+BM6hS4n9ytMn X-Gm-Gg: Acq92OFYNGpx9kn1/zqvJ4QEk5fSZsSsEIvSXJfP9iO1i+SDcDgOIczBDNx71YACSeg 35DKxx8pZ03TRHtpVBTjVe8Gwwmvp24W4c/4QQkjlm7emmBxhnDv5rmV0HDfqxsQ9eX3r/XprBv JkKgz5FWZ+gKkLMS/mAbcHAbCRxVBJGzVQzjj1XIaONKq5YzCcByvX2RQ5g3P0YFh50e7ycr/H/ HtdqY5dpR5R+FQYVWz/y1Kc/vQKi0QC+Pn5c+kZ6yh9hJuMVgnFpg1o98W631XD1y3nvuruyOjn NCUZn1okbyutjcCu+PB3u4q1zQhUjw8gNkwLRKxikpo29iDq6awB9lnL/rcM8De77Y82SlwBcBX k4SF/xEZ1SNfUzgoqCWt6ZG8Y4d82UITHdw0mInQk/jK/E6+7KkdMgNYeUcQhhe17uy7SGJ77Ha fje+Hby/8iZcn2ttR0+UgnelbV1qw8Fe6avTeQ3mIF3LKcNi1/1irOR+EgS+EpJ9058Q== X-Received: by 2002:a17:90b:5704:b0:36b:93f7:a903 with SMTP id 98e67ed59e1d1-36c501c74f8mr417577a91.18.1780080302322; Fri, 29 May 2026 11:45:02 -0700 (PDT) Received: from devvm29614.prn0.facebook.com ([2a03:2880:ff:5e::]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36bc02b8b57sm3089158a91.7.2026.05.29.11.45.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 11:45:01 -0700 (PDT) Date: Fri, 29 May 2026 11:44:55 -0700 From: Bobby Eshleman To: Jakub Kicinski Cc: alexanderduyck@fb.com, kernel-team@meta.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, linux@armlinux.org.uk, hmohsin@meta.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bobbyeshleman@meta.com Subject: Re: [PATCH net v2] eth: fbnic: move aui and fec from fbnic_net to fbnic_dev Message-ID: References: <20260526-fbnic-aui-change-v2-1-7c74cd48074f@meta.com> <20260529003714.317617-1-kuba@kernel.org> <20260528174507.3ae6fa6b@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260528174507.3ae6fa6b@kernel.org> On Thu, May 28, 2026 at 05:45:07PM -0700, Jakub Kicinski wrote: > On Thu, 28 May 2026 17:37:14 -0700 Jakub Kicinski wrote: > > > @@ -15,18 +14,14 @@ static int > > > fbnic_mdio_read_pmd(struct fbnic_dev *fbd, int addr, int regnum) > > > { > > > u8 aui = FBNIC_AUI_UNKNOWN; > > > - struct fbnic_net *fbn; > > > int ret = 0; > > > > > > /* We don't need a second PMD, just one can handle both lanes */ > > > if (addr) > > > return 0; > > > > > > - if (fbd->netdev) { > > > - fbn = netdev_priv(fbd->netdev); > > > - if (fbn->aui < FBNIC_AUI_UNKNOWN) > > > - aui = fbn->aui; > > > - } > > > + if (fbd->aui < FBNIC_AUI_UNKNOWN) > > > + aui = fbd->aui; > > > > [Severity: High] > > This isn't a bug introduced by this patch, but does moving aui and fec to > > struct fbnic_dev actually prevent a use-after-free here? > > > > If fbnic_mdiobus_create() registers the MDIO bus using > > devm_mdiobus_register(), devres-managed resources are cleaned up after the > > driver's remove callback returns. > > > > If fbnic_remove() frees the fbd structure, the bus remains fully active > > between the time the remove function finishes and the devres cleanup > > unregisters the MDIO bus. > > > > Can a concurrent sysfs access invoke MDIO read callbacks which pass fbd > > to this function, leading to a dereference of the freed fbd pointer when > > reading fbd->aui? > > Sorry for broadening the scope here a little bit but I think we should > fix this (as well). In the same series, but probably separate patch. > Just don't use devm_, it creates about as many bugs as it prevents. Sounds like a plan, I'm all for getting it right in one go. Will revise for next rev. Best, Bobby