| Message ID | 20180620213141.GA8957@beast (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Darren Hart |
| Headers | show |
On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > The probe handler_data was being allocated with __get_free_pages() > for no reason I could find. The error path was using kfree(). Since v4 of Mario's series used kmalloc: https://patchwork.kernel.org/patch/9985827/ This was changed in v10 to use __get_free_pages: https://patchwork.kernel.org/patch/10018023/ But... I'm not finding the discussion that led to this change.... Mario, do you recall? Something about contiguous memory? We had a similar discussion on an earlier series: https://patchwork.kernel.org/patch/9975277/ > other things are happily using kmalloc() in the probe path, switch to > kmalloc() entirely. This fixes the error path mismatch and will avoid > issues with CONFIG_HARDENED_USERCOPY_PAGESPAN=y. > > Reported-by: Mihai Donțu <mihai.dontu@gmail.com> > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > drivers/platform/x86/wmi.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c > index 8e3d0146ff8c..04791ea5d97b 100644 > --- a/drivers/platform/x86/wmi.c > +++ b/drivers/platform/x86/wmi.c > @@ -895,7 +895,6 @@ static int wmi_dev_probe(struct device *dev) > struct wmi_driver *wdriver = > container_of(dev->driver, struct wmi_driver, driver); > int ret = 0; > - int count; > char *buf; > > if (ACPI_FAILURE(wmi_method_enable(wblock, 1))) > @@ -917,9 +916,8 @@ static int wmi_dev_probe(struct device *dev) > goto probe_failure; > } > > - count = get_order(wblock->req_buf_size); > - wblock->handler_data = (void *)__get_free_pages(GFP_KERNEL, > - count); > + wblock->handler_data = kmalloc(wblock->req_buf_size, > + GFP_KERNEL); > if (!wblock->handler_data) { > ret = -ENOMEM; > goto probe_failure; > @@ -964,8 +962,7 @@ static int wmi_dev_remove(struct device *dev) > if (wdriver->filter_callback) { > misc_deregister(&wblock->char_dev); > kfree(wblock->char_dev.name); > - free_pages((unsigned long)wblock->handler_data, > - get_order(wblock->req_buf_size)); > + kfree(wblock->handler_data); > } > > if (wdriver->remove) > -- > 2.17.1 > > > -- > Kees Cook > Pixel Security >
On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart <dvhart@infradead.org> wrote: > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: >> The probe handler_data was being allocated with __get_free_pages() >> for no reason I could find. The error path was using kfree(). Since > > v4 of Mario's series used kmalloc: > https://patchwork.kernel.org/patch/9985827/ > > This was changed in v10 to use __get_free_pages: > https://patchwork.kernel.org/patch/10018023/ > > But... I'm not finding the discussion that led to this change.... Mario, > do you recall? Something about contiguous memory? We had a similar > discussion on an earlier series: > > https://patchwork.kernel.org/patch/9975277/ FWIW, kmalloc gets you contiguous memory... But if the reason is found and needs to stay, the probe error path's kfree() needs to be fixed, and __GFP_COMP needs to be added to the free page flags. -Kees
On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart <dvhart@infradead.org> wrote: > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > >> The probe handler_data was being allocated with __get_free_pages() > >> for no reason I could find. The error path was using kfree(). Since > > > > v4 of Mario's series used kmalloc: > > https://patchwork.kernel.org/patch/9985827/ > > > > This was changed in v10 to use __get_free_pages: > > https://patchwork.kernel.org/patch/10018023/ > > > > But... I'm not finding the discussion that led to this change.... Mario, > > do you recall? Something about contiguous memory? We had a similar > > discussion on an earlier series: > > > > https://patchwork.kernel.org/patch/9975277/ > > FWIW, kmalloc gets you contiguous memory... Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in this case. I'll give Mario a chance to respond in case I'm just missing something, but otherwise will plan to apply this patch. > > But if the reason is found and needs to stay, the probe error path's > kfree() needs to be fixed, and __GFP_COMP needs to be added to the > free page flags. Got it, thanks Kees.
> -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Wednesday, June 20, 2018 7:17 PM > To: Kees Cook > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, Mario > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart <dvhart@infradead.org> wrote: > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > >> The probe handler_data was being allocated with __get_free_pages() > > >> for no reason I could find. The error path was using kfree(). Since > > > > > > v4 of Mario's series used kmalloc: > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > This was changed in v10 to use __get_free_pages: > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > But... I'm not finding the discussion that led to this change.... Mario, > > > do you recall? Something about contiguous memory? We had a similar > > > discussion on an earlier series: > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > FWIW, kmalloc gets you contiguous memory... > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in > this case. I'll give Mario a chance to respond in case I'm just missing > something, but otherwise will plan to apply this patch. I think it was for contiguous memory, so if kmalloc is giving that I agree no need to keep __get_free_pages instead. Acked-by: Mario Limonciello <Mario.limonciello@dell.com> Thanks, > > > > > But if the reason is found and needs to stay, the probe error path's > > kfree() needs to be fixed, and __GFP_COMP needs to be added to the > > free page flags. > > Got it, thanks Kees. > > -- > Darren Hart > VMware Open Source Technology Center
On Thu, Jun 21, 2018 at 01:24:34AM +0000, Mario.Limonciello@dell.com wrote: > > -----Original Message----- > > From: Darren Hart [mailto:dvhart@infradead.org] > > Sent: Wednesday, June 20, 2018 7:17 PM > > To: Kees Cook > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, Mario > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart <dvhart@infradead.org> wrote: > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > >> The probe handler_data was being allocated with __get_free_pages() > > > >> for no reason I could find. The error path was using kfree(). Since > > > > > > > > v4 of Mario's series used kmalloc: > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > But... I'm not finding the discussion that led to this change.... Mario, > > > > do you recall? Something about contiguous memory? We had a similar > > > > discussion on an earlier series: > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in > > this case. I'll give Mario a chance to respond in case I'm just missing > > something, but otherwise will plan to apply this patch. > > I think it was for contiguous memory, so if kmalloc is giving that I agree > no need to keep __get_free_pages instead. > > Acked-by: Mario Limonciello <Mario.limonciello@dell.com> Confirmed, kmalloc in physically contiguous. Queued up, and tagged for stable. Thanks everyone.
Hi Darren, On Fri, 2018-06-22 at 16:27 -0700, Darren Hart wrote: > On Thu, Jun 21, 2018 at 01:24:34AM +0000, Mario.Limonciello@dell.com wrote: > > > -----Original Message----- > > > From: Darren Hart [mailto:dvhart@infradead.org] > > > Sent: Wednesday, June 20, 2018 7:17 PM > > > To: Kees Cook > > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, Mario > > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart <dvhart@infradead.org> wrote: > > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > > > > The probe handler_data was being allocated with __get_free_pages() > > > > > > for no reason I could find. The error path was using kfree(). Since > > > > > > > > > > v4 of Mario's series used kmalloc: > > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > > > But... I'm not finding the discussion that led to this change.... Mario, > > > > > do you recall? Something about contiguous memory? We had a similar > > > > > discussion on an earlier series: > > > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in > > > this case. I'll give Mario a chance to respond in case I'm just missing > > > something, but otherwise will plan to apply this patch. > > > > I think it was for contiguous memory, so if kmalloc is giving that I agree > > no need to keep __get_free_pages instead. > > > > Acked-by: Mario Limonciello <Mario.limonciello@dell.com> > > Confirmed, kmalloc in physically contiguous. > > Queued up, and tagged for stable. Thanks everyone. > Would it be possible to queue this for 4.18 or is it too late? I just noticed it has not reached 4.17.12 either. Thanks,
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c index 8e3d0146ff8c..04791ea5d97b 100644 --- a/drivers/platform/x86/wmi.c +++ b/drivers/platform/x86/wmi.c @@ -895,7 +895,6 @@ static int wmi_dev_probe(struct device *dev) struct wmi_driver *wdriver = container_of(dev->driver, struct wmi_driver, driver); int ret = 0; - int count; char *buf; if (ACPI_FAILURE(wmi_method_enable(wblock, 1))) @@ -917,9 +916,8 @@ static int wmi_dev_probe(struct device *dev) goto probe_failure; } - count = get_order(wblock->req_buf_size); - wblock->handler_data = (void *)__get_free_pages(GFP_KERNEL, - count); + wblock->handler_data = kmalloc(wblock->req_buf_size, + GFP_KERNEL); if (!wblock->handler_data) { ret = -ENOMEM; goto probe_failure; @@ -964,8 +962,7 @@ static int wmi_dev_remove(struct device *dev) if (wdriver->filter_callback) { misc_deregister(&wblock->char_dev); kfree(wblock->char_dev.name); - free_pages((unsigned long)wblock->handler_data, - get_order(wblock->req_buf_size)); + kfree(wblock->handler_data); } if (wdriver->remove)
The probe handler_data was being allocated with __get_free_pages() for no reason I could find. The error path was using kfree(). Since other things are happily using kmalloc() in the probe path, switch to kmalloc() entirely. This fixes the error path mismatch and will avoid issues with CONFIG_HARDENED_USERCOPY_PAGESPAN=y. Reported-by: Mihai Donțu <mihai.dontu@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> --- drivers/platform/x86/wmi.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)