[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22ab53d1ae36d4925732e6e1dc989dc75af126da.camel@sipsolutions.net>
Date: Fri, 27 Oct 2023 14:45:57 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Greg KH <gregkh@...uxfoundation.org>,
Yu Wang <quic_yyuwang@...cinc.com>
Cc: rafael@...nel.org, linux-kernel@...r.kernel.org, kernel@...cinc.com
Subject: Re: [PATCH] Devcoredump: fix use-after-free issue when releasing
devcd device
On Fri, 2023-10-27 at 13:11 +0200, Greg KH wrote:
> >
> > static void my_coredump()
> > {
> > struct my_coredump_state dump_state;
> > struct device *new_device =
> > kzalloc(sizeof(*new_device), GFP_KERNEL);
> >
> > ...
> > new_device->release = my_dev_release;
> > device_initialize(new_device);
> > ...
> > device_add(new_device);
> > ...
> > init_completion(&dump_state.dump_done);
> > dev_coredumpm(new_device, NULL, &dump_state, datalen, GFP_KERNEL,
> > my_coredump_read, my_coredump_free);
> > wait_for_completion(&dump_state.dump_done);
> > device_del(new_device);
> > put_device(new_device);
> > }
>
> Is there any in-kernel user like this? If so, why not fix them up to
> not do this?
>
Maybe this is only a simplified scenario and whenever you remove a
device when a coredump is still pending this can happen?
Actually, no, wait, what is this doing??? Why is there a completion and
all that stuff there? You shouldn't really care about the dump once you
have created it, and not pass NULL for the struct module pointer
either?!
johannes
Powered by blists - more mailing lists