All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Muhammad Bilal <meatuni001@gmail.com>
Cc: "Jorge Lopez" <jorge.lopez2@hp.com>,
	"Hans de Goede" <hansg@kernel.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	platform-driver-x86@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH v4 8/9] platform/x86: hp-bioscfg: NUL-terminate the SPM auth token
Date: Mon, 5 Oct 2026 16:41:18 +0300 (EEST)	[thread overview]
Message-ID: <ec29e795-2b9a-36de-490e-64bb843d5dc8@linux.intel.com> (raw)
In-Reply-To: <20261002191434.58529-9-meatuni001@gmail.com>

On Sat, 3 Oct 2026, Muhammad Bilal wrote:

> auth_token_store() copies the token with kmemdup(), which does not NUL
> terminate it, but hp_calculate_security_buffer() and
> hp_populate_security_buffer() treat it as a C string and read past the
> allocation.

Again here.

If something is treated as C string later, how is it valid to prepare it 
with kmemdup_nul()? I just don't follow that logic.

Either something is a string or it isn't, which way this is?

> A lone newline (echo > auth_token) is worse: kmemdup() of 0 bytes
> returns ZERO_SIZE_PTR, which passes the NULL checks, so a later
> attribute write calls strlen() on address 0x10.
> 
> Use kmemdup_nul(), which allocates one extra byte for the terminator
> and never returns ZERO_SIZE_PTR.
> 
> Compile tested only.
> 
> Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
> ---
> Changes in v4:
>  - New patch
> 
>  drivers/platform/x86/hp/hp-bioscfg/spmobj-attributes.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/hp/hp-bioscfg/spmobj-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/spmobj-attributes.c
> index f0eb5c445..19f0f9f16 100644
> --- a/drivers/platform/x86/hp/hp-bioscfg/spmobj-attributes.c
> +++ b/drivers/platform/x86/hp/hp-bioscfg/spmobj-attributes.c
> @@ -316,7 +316,7 @@ static ssize_t auth_token_store(struct kobject *kobj,
>  		length--;
>  
>  	/* allocate space and copy current auth token */
> -	bioscfg_drv.spm_data.auth_token = kmemdup(buf, length, GFP_KERNEL);
> +	bioscfg_drv.spm_data.auth_token = kmemdup_nul(buf, length, GFP_KERNEL);
>  	if (!bioscfg_drv.spm_data.auth_token) {
>  		ret = -ENOMEM;
>  		goto exit_token;
> 

-- 
 i.


  reply	other threads:[~2026-10-05 13:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 19:14 [PATCH v4 0/9] platform/x86: hp-bioscfg: buffer handling fixes Muhammad Bilal
2026-10-02 19:14 ` [PATCH v4 1/9] platform/x86: hp-bioscfg: fix OOB reads in hp_get_string_from_buffer() Muhammad Bilal
2026-10-03 20:14   ` Andy Shevchenko
2026-10-02 19:14 ` [PATCH v4 2/9] platform/x86: hp-bioscfg: fix non-ASCII truncation " Muhammad Bilal
2026-10-02 19:14 ` [PATCH v4 3/9] platform/x86: hp-bioscfg: return -E2BIG from validate_password_input() Muhammad Bilal
2026-10-02 19:14 ` [PATCH v4 4/9] platform/x86: hp-bioscfg: allow clearing current_password Muhammad Bilal
2026-10-05 13:13   ` Ilpo Järvinen
2026-10-02 19:14 ` [PATCH v4 5/9] platform/x86: hp-bioscfg: fix off-by-one in password length check Muhammad Bilal
2026-10-02 19:14 ` [PATCH v4 6/9] platform/x86: hp-bioscfg: fix heap OOB with embedded NUL in store paths Muhammad Bilal
2026-10-05 13:25   ` Ilpo Järvinen
2026-10-02 19:14 ` [PATCH v4 7/9] platform/x86: hp-bioscfg: validate SPM state returned by firmware Muhammad Bilal
2026-10-05 13:28   ` Ilpo Järvinen
2026-10-02 19:14 ` [PATCH v4 8/9] platform/x86: hp-bioscfg: NUL-terminate the SPM auth token Muhammad Bilal
2026-10-05 13:41   ` Ilpo Järvinen [this message]
2026-10-02 19:14 ` [PATCH v4 9/9] platform/x86: hp-bioscfg: fix oops on short integer attribute buffer Muhammad Bilal

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=ec29e795-2b9a-36de-490e-64bb843d5dc8@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hansg@kernel.org \
    --cc=jorge.lopez2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=meatuni001@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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.