From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.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 765B52BD01B for ; Sat, 21 Feb 2026 00:56:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771635379; cv=none; b=t2Zt7y2yQxB49QuxUDAjvz9rDSMISL+4PZ8h/eZqlKK8U/Mvye7Mkm4ttHmopy+CEvELGJ1kUUjNWqpvtmnsq/CC5uyS2nBtAw2QMoUgQYT9zTClEyrLHf+KIpV3EMd00vdxE0v4d20y7I22rauAMZm6BIIfbPXOpP0j0jGa9L4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771635379; c=relaxed/simple; bh=wlZDSkm6dCKIC/yRs3a//+3oanKk/T1jmwR5qGC3nlo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tIKch9AeeRrqGXppFGq1ySi45RIfipeBxt3XfY8LAkSnNCyQ2uV3MDt4v0q1tQUi6kHK4tUA+dF6ug6aPqfYQOt1YyxhjurRB64zUJ+7D2y62DvK9Y73UhAAJSBbUOjewx3GIPnpZMOUiASINnHIXBWm94Cj23EeNOiRoI636SI= 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=HkjRGHbB; arc=none smtp.client-ip=74.125.82.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="HkjRGHbB" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-124afd03fd1so3617092c88.0 for ; Fri, 20 Feb 2026 16:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771635376; x=1772240176; 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=rAuHkLoWGxu4w6ydGTuoVLuEOItX13UcgZ4dNROHNx0=; b=HkjRGHbBmsmC7OEHdNa8IUn57y1DBWNpYPle3CtOvWD9nmU+eeFDIXur44KpWzRJz+ 4fgvENId1+QZbF7jUNrzExdh1kVkyRYoRVOQ/wOIpJG9dVVHms8kqzyu3CHgYMMWvzDG XwtvscabcmwLdruWjdipyQx1AEaK5eu/U1ONfkmoywibzwIfw06tzaCnTR2fHPeKvDPU rTQHkPx9TR69Xs2IS6B6hgBprUBK9Pc5rHJ4diDuFHq6LeMm0Dqbu1WbizU6N8hdeZ1q bOA8r+vf5ek/Wh8cKf05Y/bVzbOWLFcpF2mtUEGNKHv07uo4QdNsCY6r4OFZl+zWLnlJ kRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771635377; x=1772240177; 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=rAuHkLoWGxu4w6ydGTuoVLuEOItX13UcgZ4dNROHNx0=; b=MTLbnjXm0I4jxRjUR3+FMD9cRl4e6FelfaVFsuvsFs1BQMsfxdWfT3lXBuIhmvm6Ef b7I4mzM2Yznxi0wXAxhO+x0FPGoebXdqyzwfjPgD8RdXV3PpnoBapR7thfDqxh8QY1Nl 0lfTD7SQ0GDyOXKBOmSIEdG6p+Xl+1pK1csjVMKEYhHdxmo72pn3ztgwOoe68F5inOp0 s2LdiYwwwP25aTb3CjTPebyBNsjZMMrus9e0/XYZyp+XhiSIGdsQpR0dslkr+k9f9BRq kw4GLuyRmRIBCYaVfm7r94nPaF+jaCipnDHX5y7H5p44+LEHhRIZ72+ObLbEw7VzCfFX 2Wcw== X-Forwarded-Encrypted: i=1; AJvYcCWi6jboRWdYrGgKPO4MKgbvu/uhptetAtZXONkTzvw2vh9SXbYuBSmcBNxYkN4/06LlWqq4WJJDoruFuBo=@vger.kernel.org X-Gm-Message-State: AOJu0YxvlyGiObZkDRmTxWpxOmD0YsKDlzMp+DizGtb7G7YyLbCYsTHD PuRGIrRZdS9xA446gwEPhzTmyH+HJ/ir4Eb2oK3LkbdtlbfzHvzD07gt X-Gm-Gg: AZuq6aLuF3Ee2dr2n/W9TjyhRojEJ52+5DUxYBnJLEvFhtUKlb+OK60evCMMPBNBktI ibIXKPVTDM36JWyn1Blkg3WHmwI5NbFZfKCb82Gn7pZwc973rMy/BISnkHsYL3z/06vgkEPal6C Zq/w15HdjMzu6Vi2jNoczNGQPbBE6qilvfnv/HeT+ckxcysO3WAUaqXo6ATfJ2DEMMrvwVEsvYL Z2vOq5DaGsIZNGt7OXcohGpRZdMZEmxkm6+0J6XQ2hYZo/hLMYMXoyBMJtNiy8KjChtUHPQM8Xz aJadOLN8MfHL7Th2pAGwDnLXkP0r+r37SvnH1H3Y7NLgtNtNqSJbAs4OS2RQbr6AWvjNxumlesq th+sIiil+ixs15MSVJTXVTylclLRKosFu12bIZoerZITjCZXgDvgal7MC1sptdHlqasRDkxY3sV 8bE8GVdHTUZ3BuO4M8vpCU2mHY1Ck9fg4m9ybOczQIx6/ElMjhppOm3+YnUdFG99bx2gMtg+BTF 5s= X-Received: by 2002:a05:7022:6607:b0:123:35a4:e8be with SMTP id a92af1059eb24-1276acc047amr629943c88.13.1771635376447; Fri, 20 Feb 2026 16:56:16 -0800 (PST) Received: from google.com ([2a00:79e0:2ebe:8:30e0:64af:2b48:14be]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1276af7ad65sm795757c88.11.2026.02.20.16.56.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Feb 2026 16:56:16 -0800 (PST) Date: Fri, 20 Feb 2026 16:56:12 -0800 From: Dmitry Torokhov To: Jakub Kicinski Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , "Rafael J. Wysocki" , Simon Horman , Zijun Hu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: wan: framer: fix potential UAF in framer_provider_simple_of_xlate() Message-ID: References: <20260220162553.3beafdcc@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: <20260220162553.3beafdcc@kernel.org> On Fri, Feb 20, 2026 at 04:25:53PM -0800, Jakub Kicinski wrote: > On Thu, 19 Feb 2026 15:40:57 -0800 Dmitry Torokhov wrote: > > The implementation put_device()s located device and then uses > > container_of() on the pointer. The device may disappear by that time, > > resulting in UAF. > > > > Fix the problem by keeping the reference to the framer device, and > > avoid getting an extra reference to it in framer_get(). > > I have failed to understand what you are talking about after looking > at this for 15min :S Please write better commit messages? Yeah, I should probably rephrase it, container_of() is not that important. The core of the issue that once you do put_device() it may disappear, so when you do return dev_to_framer(target_dev); the returned pointer may no longer point to the valid framer device. The memory may get used for something else entirely. You have to hold on to the reference until you are completely done with the device. > > > Fixes: dcacb364772e ("net: wan: framer: Simplify API framer_provider_simple_of_xlate() implementation") > > Signed-off-by: Dmitry Torokhov > > --- > > drivers/net/wan/framer/framer-core.c | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/drivers/net/wan/framer/framer-core.c b/drivers/net/wan/framer/framer-core.c > > index bf7ac7dd2804..397fabc3da4e 100644 > > --- a/drivers/net/wan/framer/framer-core.c > > +++ b/drivers/net/wan/framer/framer-core.c > > @@ -482,8 +482,6 @@ struct framer *framer_get(struct device *dev, const char *con_id) > > if (IS_ERR(framer)) > > return framer; > > > > - get_device(&framer->dev); > > AFAICT this get_device() does not pair with the put_device() > you are removing It does not "pair", but it tries to bump up a reference to the device we just did "put" on in framer_provider_simple_of_xlate(). If we remove put there as I propose then we do not need to do it here, or we'll end up with an extra reference. > > > if (!try_module_get(framer->ops->owner)) { > > ret = -EPROBE_DEFER; > > goto err_put_device; > > @@ -749,7 +747,6 @@ struct framer *framer_provider_simple_of_xlate(struct device *dev, > > if (!target_dev) > > return ERR_PTR(-ENODEV); > > > > - put_device(target_dev); > > return dev_to_framer(target_dev); > > The only caller of this function does not dereference the pointer > (no idea why it even calls it, for some setup validation?) The returned pointer ends up in framer_get() through a few layers. > Calling container_of() on a stale pointer is safe. But using what it returns isn't. And I am sure there is an arcane C rule that disallows container_of and gives compiler a license to kill a kitten. > > > } > > EXPORT_SYMBOL_GPL(framer_provider_simple_of_xlate); > > I'm kinda curious about the backstory for this patch.. > What made you look at this code? I want to remove class_find_device_by_of_node() in favor of class_find_device_by_fwnode() so I happened to look at the code. Thanks. -- Dmitry