[PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Kees Cook]

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(-)

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

Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Darren Hart]

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
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Kees Cook]

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

-- 
Kees Cook
Pixel Security

Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Darren Hart]

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.

-- 
Darren Hart
VMware Open Source Technology Center

RE: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Mario.Limonciello]

> -----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

Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Darren Hart]

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.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc

[Mihai Donțu]

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,

-- 
Mihai Donțu