public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Yu Wang <quic_yyuwang@quicinc.com>,
	rafael@kernel.org, linux-kernel@vger.kernel.org,
	kernel@quicinc.com
Subject: Re: [PATCH] Devcoredump: fix use-after-free issue when releasing devcd device
Date: Tue, 31 Oct 2023 14:02:43 +0100	[thread overview]
Message-ID: <2023103119-litigator-yonder-6ee1@gregkh> (raw)
In-Reply-To: <bb8113aa-1573-5e02-3fcd-bd92b8ac14ba@quicinc.com>

On Tue, Oct 31, 2023 at 06:16:08PM +0530, Mukesh Ojha wrote:
> 
> 
> On 10/31/2023 2:29 PM, Johannes Berg wrote:
> > On Tue, 2023-10-31 at 16:29 +0800, Yu Wang wrote:
> > > 
> > > In this case, the device is temporarily added for dump only, so we need to
> > > delete it when dump is completed.
> > > The other users doesn't add/delete the device like this.
> > 
> > For good reason, I guess? I think this is probably a bad idea.
> > 
> > The whole point of this was to actually know which device created the
> > coredump? If you make one up on the fly that's ... pointless? Surely you
> > must have _some_ device that already exists?
> 
> Passing device name to be user space looks to be the reason.

Wait, again, why are you creating a fake device just to dump data?
That's not what this api is for at all, why are you abusing it in ways
it was not designed to be used?

And I will strongly argue, that if no in-kernel users are having
problems, perhaps it is your out-of-tree code?

Unless you can show any in-kernel user of this trigging the issue, I
don't think there's anything we need to do here, do you?

thanks,

greg k-h

  reply	other threads:[~2023-10-31 13:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27  5:55 [PATCH] Devcoredump: fix use-after-free issue when releasing devcd device Yu Wang
2023-10-27  6:22 ` Mukesh Ojha
2023-10-28  9:20   ` Mukesh Ojha
2023-10-27  6:23 ` Mukesh Ojha
2023-10-27  6:55   ` Mukesh Ojha
2023-10-27 11:11 ` Greg KH
     [not found]   ` <22ab53d1ae36d4925732e6e1dc989dc75af126da.camel@sipsolutions.net>
2023-10-31  8:29     ` Yu Wang
2023-10-31  8:59       ` Johannes Berg
2023-10-31 12:46         ` Mukesh Ojha
2023-10-31 13:02           ` Greg KH [this message]
2023-10-27 11:12 ` Greg KH
2023-10-31  7:15   ` Yu Wang
2023-10-31  7:39     ` Greg KH
2023-10-31  9:41       ` Yu Wang
2023-10-31  9:50         ` Greg KH

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=2023103119-litigator-yonder-6ee1@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=kernel@quicinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=quic_yyuwang@quicinc.com \
    --cc=rafael@kernel.org \
    /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