All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Hung-Te Lin <hungte@chromium.org>
Cc: hungte@chromium.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexios Zavras <alexios.zavras@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	Samuel Holland <samuel@sholland.org>,
	Allison Randal <allison@lohutok.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] firmware: google: check if size is valid when decoding VPD data
Date: Thu, 29 Aug 2019 07:51:30 -0700	[thread overview]
Message-ID: <5d67e673.1c69fb81.5f13b.62ee@mx.google.com> (raw)
In-Reply-To: <20190829114547.9957-1-hungte@chromium.org>

Quoting Hung-Te Lin (2019-08-29 04:45:43)
> The VPD implementation from Chromium Vital Product Data project used to
> parse data from untrusted input without checking if the meta data is
> invalid or corrupted. For example, the size from decoded content may
> be negative value, or larger than whole input buffer. Such invalid data
> may cause buffer overflow.
> 
> To fix that, the size parameters passed to vpd_decode functions should
> be changed to unsigned integer (u32) type, and the parsing of entry
> header should be refactored so every size field is correctly verified
> before starting to decode.
> 
> Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files")
> Signed-off-by: Hung-Te Lin <hungte@chromium.org>
> ---

Two minor nitpicks, otherwise

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

> diff --git a/drivers/firmware/google/vpd_decode.c b/drivers/firmware/google/vpd_decode.c
> index 92e3258552fc..7a5b0c72db00 100644
> --- a/drivers/firmware/google/vpd_decode.c
> +++ b/drivers/firmware/google/vpd_decode.c
> @@ -9,8 +9,8 @@
>  
>  #include "vpd_decode.h"
>  
> -static int vpd_decode_len(const s32 max_len, const u8 *in,
> -                         s32 *length, s32 *decoded_len)
> +static int vpd_decode_len(const u32 max_len, const u8 *in, u32 *length,
> +                         u32 *decoded_len)

Nitpick: Can you leave the first line alone? Just change types from s32
to u32 on the same line so that this hunk clearly shows that the
function name and other arguments aren't changing.

>  {
>         u8 more;
>         int i = 0;
> diff --git a/drivers/firmware/google/vpd_decode.h b/drivers/firmware/google/vpd_decode.h
> index cf8c2ace155a..b65d246a6804 100644
> --- a/drivers/firmware/google/vpd_decode.h
> +++ b/drivers/firmware/google/vpd_decode.h
> @@ -25,15 +25,14 @@ enum {
[...]
>  
>  /*
>   * vpd_decode_string
>   *
>   * Given the encoded string, this function invokes callback with extracted
> - * (key, value). The *consumed will be plused the number of bytes consumed in
> + * (key, value). The *consumed will be plused by the number of bytes consumed in
>   * this function.
>   *
>   * The input_buf points to the first byte of the input buffer.

This part can be a different patch that also converts this to kernel-doc
style. See Documentation/doc-guide/kernel-doc.rst for more info.


  reply	other threads:[~2019-08-29 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02  8:20 [PATCH] firmware: google: update vpd_decode from upstream Hung-Te Lin
2019-08-02 22:27 ` Stephen Boyd
2019-08-07 13:58   ` Guenter Roeck
2019-08-07 14:59     ` Stephen Boyd
2019-08-07 16:50       ` Guenter Roeck
2019-08-29 10:19         ` [PATCH v2] " Hung-Te Lin
2019-08-29 11:24           ` Greg Kroah-Hartman
2019-08-29 11:45             ` [PATCH v3] firmware: google: check if size is valid when decoding VPD data Hung-Te Lin
2019-08-29 14:51               ` Stephen Boyd [this message]
2019-08-30  2:23                 ` [PATCH v4] " Hung-Te Lin
2019-08-30  5:03                   ` Stephen Boyd
2019-08-30 16:54                   ` Guenter Roeck

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=5d67e673.1c69fb81.5f13b.62ee@mx.google.com \
    --to=swboyd@chromium.org \
    --cc=alexios.zavras@intel.com \
    --cc=allison@lohutok.net \
    --cc=colin.king@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hungte@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=samuel@sholland.org \
    --cc=tglx@linutronix.de \
    /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.