All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Chen Yu <yu.c.chen@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl()
Date: Mon, 10 Jan 2022 09:17:13 +0300	[thread overview]
Message-ID: <20220110061713.GA1951@kadam> (raw)
In-Reply-To: <20220107134617.GA895400@chenyu-desktop>

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


  reply	other threads:[~2022-01-10  6:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-01-10 15:39     ` Rafael J. Wysocki
2022-01-11  1:09       ` Chen Yu
2022-01-11  0:56     ` Chen Yu

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=20220110061713.GA1951@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=yu.c.chen@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.