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
next prev parent 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