public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Paolo Abeni <pabeni@redhat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	 Simon Horman <horms@kernel.org>,
	Zijun Hu <zijun.hu@oss.qualcomm.com>,
	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()
Date: Fri, 20 Feb 2026 16:56:12 -0800	[thread overview]
Message-ID: <aZkAaoBxb8j3FqGr@google.com> (raw)
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 <dmitry.torokhov@gmail.com>
> > ---
> >  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

  reply	other threads:[~2026-02-21  0:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-19 23:40 [PATCH net] net: wan: framer: fix potential UAF in framer_provider_simple_of_xlate() Dmitry Torokhov
2026-02-21  0:25 ` Jakub Kicinski
2026-02-21  0:56   ` Dmitry Torokhov [this message]
2026-02-21  1:13     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZkAaoBxb8j3FqGr@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=zijun.hu@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox