linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
@ 2022-01-07  7:34 Dan Carpenter
  2022-01-07 13:46 ` Chen Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Dan Carpenter @ 2022-01-07  7:34 UTC (permalink / raw)
  To: Rafael J. Wysocki, Chen Yu
  Cc: Len Brown, linux-acpi, linux-kernel, kernel-janitors

The "data_info" struct is copied to the user.  It has a 4 byte struct
hole after the last struct member so we need to memset that to avoid
copying uninitialized stack data to the user.

Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
When you're adding a new driver to the kernel then please use the new
driver's prefix instead of just the subsystem prefix.

 Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver

Otherwise it's just up to me to guess what prefix you wanted.

 drivers/acpi/pfr_telemetry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
index da50dd80192c..9abf350bd7a5 100644
--- a/drivers/acpi/pfr_telemetry.c
+++ b/drivers/acpi/pfr_telemetry.c
@@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
 	union acpi_object *out_obj, in_obj, in_buf;
 	int ret = -EBUSY;
 
+	memset(data_info, 0, sizeof(*data_info));
 	memset(&in_obj, 0, sizeof(in_obj));
 	memset(&in_buf, 0, sizeof(in_buf));
 	in_obj.type = ACPI_TYPE_PACKAGE;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
  2022-01-07  7:34 [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl() Dan Carpenter
@ 2022-01-07 13:46 ` Chen Yu
  2022-01-10  6:17   ` Dan Carpenter
  0 siblings, 1 reply; 6+ messages in thread
From: Chen Yu @ 2022-01-07 13:46 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel, kernel-janitors

On Fri, Jan 07, 2022 at 10:34:07AM +0300, Dan Carpenter wrote:
> The "data_info" struct is copied to the user.  It has a 4 byte struct
> hole after the last struct member so we need to memset that to avoid
> copying uninitialized stack data to the user.
> 
> Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> When you're adding a new driver to the kernel then please use the new
> driver's prefix instead of just the subsystem prefix.
> 
>  Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
> Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver
> 
Thanks for pointing this out.
> Otherwise it's just up to me to guess what prefix you wanted.
> 
>  drivers/acpi/pfr_telemetry.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
> index da50dd80192c..9abf350bd7a5 100644
> --- a/drivers/acpi/pfr_telemetry.c
> +++ b/drivers/acpi/pfr_telemetry.c
> @@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
>  	union acpi_object *out_obj, in_obj, in_buf;
>  	int ret = -EBUSY;
>  
> +	memset(data_info, 0, sizeof(*data_info));
Just one minor question, how about moving above before:
data_info->status = out_obj->package.elements[LOG_STATUS_IDX].integer.value;
after the sanity check of the _DSM result?

thanks,
Chenyu 
>  	memset(&in_obj, 0, sizeof(in_obj));
>  	memset(&in_buf, 0, sizeof(in_buf));
>  	in_obj.type = ACPI_TYPE_PACKAGE;

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
  2022-01-07 13:46 ` Chen Yu
@ 2022-01-10  6:17   ` Dan Carpenter
  2022-01-10 15:39     ` Rafael J. Wysocki
  2022-01-11  0:56     ` Chen Yu
  0 siblings, 2 replies; 6+ messages in thread
From: Dan Carpenter @ 2022-01-10  6:17 UTC (permalink / raw)
  To: Chen Yu
  Cc: Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel, kernel-janitors

On Fri, Jan 07, 2022 at 09:46:17PM +0800, Chen Yu wrote:
> On Fri, Jan 07, 2022 at 10:34:07AM +0300, Dan Carpenter wrote:
> > The "data_info" struct is copied to the user.  It has a 4 byte struct
> > hole after the last struct member so we need to memset that to avoid
> > copying uninitialized stack data to the user.
> > 
> > Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > When you're adding a new driver to the kernel then please use the new
> > driver's prefix instead of just the subsystem prefix.
> > 
> >  Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
> > Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver
> > 
> Thanks for pointing this out.
> > Otherwise it's just up to me to guess what prefix you wanted.
> > 
> >  drivers/acpi/pfr_telemetry.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
> > index da50dd80192c..9abf350bd7a5 100644
> > --- a/drivers/acpi/pfr_telemetry.c
> > +++ b/drivers/acpi/pfr_telemetry.c
> > @@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
> >  	union acpi_object *out_obj, in_obj, in_buf;
> >  	int ret = -EBUSY;
> >  
> > +	memset(data_info, 0, sizeof(*data_info));
> Just one minor question, how about moving above before:
> data_info->status = out_obj->package.elements[LOG_STATUS_IDX].integer.value;
> after the sanity check of the _DSM result?

I guess I wanted to keep all the memsets together.  I feel like if the
data is invalid, then it's going to be a slow path and it's not worth
optimizing that case.  If the data is invalid then a little slow down is
the least of our concerns.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
  2022-01-10  6:17   ` Dan Carpenter
@ 2022-01-10 15:39     ` Rafael J. Wysocki
  2022-01-11  1:09       ` Chen Yu
  2022-01-11  0:56     ` Chen Yu
  1 sibling, 1 reply; 6+ messages in thread
From: Rafael J. Wysocki @ 2022-01-10 15:39 UTC (permalink / raw)
  To: Dan Carpenter, Chen Yu
  Cc: Rafael J. Wysocki, Len Brown, ACPI Devel Maling List,
	Linux Kernel Mailing List, kernel-janitors

On Mon, Jan 10, 2022 at 7:17 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Fri, Jan 07, 2022 at 09:46:17PM +0800, Chen Yu wrote:
> > On Fri, Jan 07, 2022 at 10:34:07AM +0300, Dan Carpenter wrote:
> > > The "data_info" struct is copied to the user.  It has a 4 byte struct
> > > hole after the last struct member so we need to memset that to avoid
> > > copying uninitialized stack data to the user.
> > >
> > > Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > ---
> > > When you're adding a new driver to the kernel then please use the new
> > > driver's prefix instead of just the subsystem prefix.
> > >
> > >  Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
> > > Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver
> > >
> > Thanks for pointing this out.
> > > Otherwise it's just up to me to guess what prefix you wanted.
> > >
> > >  drivers/acpi/pfr_telemetry.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
> > > index da50dd80192c..9abf350bd7a5 100644
> > > --- a/drivers/acpi/pfr_telemetry.c
> > > +++ b/drivers/acpi/pfr_telemetry.c
> > > @@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
> > >     union acpi_object *out_obj, in_obj, in_buf;
> > >     int ret = -EBUSY;
> > >
> > > +   memset(data_info, 0, sizeof(*data_info));
> > Just one minor question, how about moving above before:
> > data_info->status = out_obj->package.elements[LOG_STATUS_IDX].integer.value;
> > after the sanity check of the _DSM result?
>
> I guess I wanted to keep all the memsets together.  I feel like if the
> data is invalid, then it's going to be a slow path and it's not worth
> optimizing that case.  If the data is invalid then a little slow down is
> the least of our concerns.

Patch applied, thanks!

Yu, this series needs to spend a few days more in linux-next, because
of the fixes against it sent lately.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
  2022-01-10  6:17   ` Dan Carpenter
  2022-01-10 15:39     ` Rafael J. Wysocki
@ 2022-01-11  0:56     ` Chen Yu
  1 sibling, 0 replies; 6+ messages in thread
From: Chen Yu @ 2022-01-11  0:56 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel, kernel-janitors

On Mon, Jan 10, 2022 at 09:17:13AM +0300, Dan Carpenter wrote:
> On Fri, Jan 07, 2022 at 09:46:17PM +0800, Chen Yu wrote:
> > On Fri, Jan 07, 2022 at 10:34:07AM +0300, Dan Carpenter wrote:
> > > The "data_info" struct is copied to the user.  It has a 4 byte struct
> > > hole after the last struct member so we need to memset that to avoid
> > > copying uninitialized stack data to the user.
> > > 
> > > Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > ---
> > > When you're adding a new driver to the kernel then please use the new
> > > driver's prefix instead of just the subsystem prefix.
> > > 
> > >  Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
> > > Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver
> > > 
> > Thanks for pointing this out.
> > > Otherwise it's just up to me to guess what prefix you wanted.
> > > 
> > >  drivers/acpi/pfr_telemetry.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
> > > index da50dd80192c..9abf350bd7a5 100644
> > > --- a/drivers/acpi/pfr_telemetry.c
> > > +++ b/drivers/acpi/pfr_telemetry.c
> > > @@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
> > >  	union acpi_object *out_obj, in_obj, in_buf;
> > >  	int ret = -EBUSY;
> > >  
> > > +	memset(data_info, 0, sizeof(*data_info));
> > Just one minor question, how about moving above before:
> > data_info->status = out_obj->package.elements[LOG_STATUS_IDX].integer.value;
> > after the sanity check of the _DSM result?
> 
> I guess I wanted to keep all the memsets together.  I feel like if the
> data is invalid, then it's going to be a slow path and it's not worth
> optimizing that case.  If the data is invalid then a little slow down is
> the least of our concerns.
>
Ok, got it.

thanks,
Chenyu 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
  2022-01-10 15:39     ` Rafael J. Wysocki
@ 2022-01-11  1:09       ` Chen Yu
  0 siblings, 0 replies; 6+ messages in thread
From: Chen Yu @ 2022-01-11  1:09 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Dan Carpenter, Len Brown, ACPI Devel Maling List,
	Linux Kernel Mailing List, kernel-janitors

On Mon, Jan 10, 2022 at 04:39:30PM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 10, 2022 at 7:17 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Fri, Jan 07, 2022 at 09:46:17PM +0800, Chen Yu wrote:
> > > On Fri, Jan 07, 2022 at 10:34:07AM +0300, Dan Carpenter wrote:
> > > > The "data_info" struct is copied to the user.  It has a 4 byte struct
> > > > hole after the last struct member so we need to memset that to avoid
> > > > copying uninitialized stack data to the user.
> > > >
> > > > Fixes: b0013e037a8b ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > ---
> > > > When you're adding a new driver to the kernel then please use the new
> > > > driver's prefix instead of just the subsystem prefix.
> > > >
> > > >  Bad: ACPI: Introduce Platform Firmware Runtime Telemetry driver
> > > > Good: ACPI / pfr_telemetry: Introduce Platform Firmware Runtime Telemetry driver
> > > >
> > > Thanks for pointing this out.
> > > > Otherwise it's just up to me to guess what prefix you wanted.
> > > >
> > > >  drivers/acpi/pfr_telemetry.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/acpi/pfr_telemetry.c b/drivers/acpi/pfr_telemetry.c
> > > > index da50dd80192c..9abf350bd7a5 100644
> > > > --- a/drivers/acpi/pfr_telemetry.c
> > > > +++ b/drivers/acpi/pfr_telemetry.c
> > > > @@ -83,6 +83,7 @@ static int get_pfrt_log_data_info(struct pfrt_log_data_info *data_info,
> > > >     union acpi_object *out_obj, in_obj, in_buf;
> > > >     int ret = -EBUSY;
> > > >
> > > > +   memset(data_info, 0, sizeof(*data_info));
> > > Just one minor question, how about moving above before:
> > > data_info->status = out_obj->package.elements[LOG_STATUS_IDX].integer.value;
> > > after the sanity check of the _DSM result?
> >
> > I guess I wanted to keep all the memsets together.  I feel like if the
> > data is invalid, then it's going to be a slow path and it's not worth
> > optimizing that case.  If the data is invalid then a little slow down is
> > the least of our concerns.
> 
> Patch applied, thanks!
> 
> Yu, this series needs to spend a few days more in linux-next, because
> of the fixes against it sent lately.
Ok, I see.

thanks,
Chenyu

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-01-11  1:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-07  7:34 [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl() Dan Carpenter
2022-01-07 13:46 ` Chen Yu
2022-01-10  6:17   ` Dan Carpenter
2022-01-10 15:39     ` Rafael J. Wysocki
2022-01-11  1:09       ` Chen Yu
2022-01-11  0:56     ` Chen Yu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).