All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ross Lagerwall <ross.lagerwall@citrix.com>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-efi@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Tony Luck <tony.luck@intel.com>,
	Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block
Date: Wed, 23 Jan 2019 12:54:02 +0100	[thread overview]
Message-ID: <20190123115402.GB3227@zn.tnic> (raw)
In-Reply-To: <20190122160912.27312-3-ross.lagerwall@citrix.com>

On Tue, Jan 22, 2019 at 04:09:12PM +0000, Ross Lagerwall wrote:
> When checking a generic status block, we iterate over all the generic
> data blocks. The loop condition only checks that the start of the
> generic data block is valid (within estatus->data_length) but not the
> whole block. Because the size of data blocks (excluding error data) may
> vary depending on the revision and the revision is contained within the
> data block, ensure that enough of the current data block is valid before
> dereferencing any members otherwise an OOB access may occur if

Please write out the OOB abbreviation in your commit messages.

> estatus->data_length is invalid. This relies on the fact that
> struct acpi_hest_generic_data_v300 is a superset of the earlier version.
> Also rework the other checks to avoid potential underflow.
> 
> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
> ---
>  drivers/firmware/efi/cper.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index a7902fccdcfa..7cc18874b9d0 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -546,7 +546,7 @@ EXPORT_SYMBOL_GPL(cper_estatus_check_header);
>  int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
>  {
>  	struct acpi_hest_generic_data *gdata;
> -	unsigned int data_len, gedata_len;
> +	unsigned int data_len, record_len;
>  	int rc;
>  
>  	rc = cper_estatus_check_header(estatus);
> @@ -555,10 +555,12 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
>  	data_len = estatus->data_length;
>  
>  	apei_estatus_for_each_section(estatus, gdata) {
> -		gedata_len = acpi_hest_get_error_length(gdata);
> -		if (gedata_len > data_len - acpi_hest_get_size(gdata))
> +		if (sizeof(struct acpi_hest_generic_data) > data_len)
>  			return -EINVAL;

<---- newline here.

Also, add a new line before the data_len assignment above, in the function.

> -		data_len -= acpi_hest_get_record_size(gdata);
> +		record_len = acpi_hest_get_record_size(gdata);

record_size so that it matches the function name it is used to compute
this.

Btw, trying to grok this code is making my head spin.

> +		if (record_len > data_len)
> +			return -EINVAL;

<---- newline here.

Btw, those checks in the loop you can abstract away into a separate
function so that you end up with something more readable like:

        apei_estatus_for_each_section(estatus, gdata) {
                record_size = check_hest_record_size(gdata, data_len);
                if (!record_size)
                        return -EINVAL;

                data_len -= record_size;
        }

for example.

> +		data_len -= record_len;
>  	}
>  	if (data_len)
>  		return -EINVAL;
> -- 

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  reply	other threads:[~2019-01-23 11:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 16:09 [PATCH 0/2] Fix crash in cper_estatus_check() Ross Lagerwall
2019-01-22 16:09 ` Ross Lagerwall
2019-01-22 16:09 ` [PATCH 1/2] acpi/apei: Avoid possible OOB when accessing BERT region Ross Lagerwall
2019-01-22 16:09   ` Ross Lagerwall
2019-01-22 16:09 ` [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block Ross Lagerwall
2019-01-22 16:09   ` Ross Lagerwall
2019-01-23 11:54   ` Borislav Petkov [this message]
2019-01-28 10:04     ` Ross Lagerwall
2019-01-28 10:04       ` Ross Lagerwall

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=20190123115402.GB3227@zn.tnic \
    --to=bp@alien8.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=ross.lagerwall@citrix.com \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@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.