linux-kernel - Re: [PATCH v2] platform/x86/amd/pmf: Use memdup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 27 May 2024 13:38:53 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Thorsten Blum <thorsten.blum@...lux.com>
Cc: markus.elfring@....de, Shyam-sundar.S-k@....com, hdegoede@...hat.com,
	ilpo.jarvinen@...ux.intel.com, kernel-janitors@...r.kernel.org,
	linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v2] platform/x86/amd/pmf: Use memdup_user()

On Mon, May 27, 2024 at 10:36:29AM +0200, Thorsten Blum wrote:
> Switch to memdup_user() to overwrite the allocated memory only once
> instead of initializing the allocated memory to zero with kzalloc() and
> then immediately overwriting it with copy_from_user().
> 
> Fix the following Coccinelle/coccicheck warning reported by
> memdup_user.cocci:
> 
> 	WARNING opportunity for memdup_user
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@...lux.com>
> ---
> Changes in v2:
> - Update patch description after feedback from Markus Elfring

Markus always CC's kernel-janitors even though I have asked him not to.
:(

> ---
>  drivers/platform/x86/amd/pmf/tee-if.c | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/platform/x86/amd/pmf/tee-if.c b/drivers/platform/x86/amd/pmf/tee-if.c
> index b438de4d6bfc..1b53cabc9aa2 100644
> --- a/drivers/platform/x86/amd/pmf/tee-if.c
> +++ b/drivers/platform/x86/amd/pmf/tee-if.c
> @@ -301,14 +301,9 @@ static ssize_t amd_pmf_get_pb_data(struct file *filp, const char __user *buf,
>  		return -EINVAL;

This -EINVAL check could be made stricter.  Instead of checking for
zero it could check for the limit from amd_pmf_start_policy_engine():

	if (dev->policy_sz < POLICY_COOKIE_OFFSET + sizeof(*header))
		return -EINVAL;

Also this check isn't great:

	if (dev->policy_sz < header->length + 512)

header->length is a u32 that comes from the user, so the addition can
overflow.  I can't immediately see how to exploit this though since we
don't seem to use header->length after this (by itself).

regards,
dan carpenter