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]
Message-ID: <2025070125-ice-outbreak-3e02@gregkh>
Date: Tue, 1 Jul 2025 07:49:05 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Akshay Gupta <akshay.gupta@....com>
Cc: linux-kernel@...r.kernel.org, arnd@...db.de, shyam-sundar.s-k@....com,
	gautham.shenoy@....com, mario.limonciello@....com,
	naveenkrishna.chatradhi@....com, anand.umarji@....com,
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH v3 1/2] misc: amd-sbi: Address potential integer overflow
 issue reported in smatch

On Tue, Jul 01, 2025 at 05:40:40AM +0000, Akshay Gupta wrote:
> Smatch warnings are reported for below commit,
> 
> Commit bb13a84ed6b7 ("misc: amd-sbi: Add support for CPUID protocol")
> from Apr 28, 2025 (linux-next), leads to the following Smatch static
> checker warning:
> 
> drivers/misc/amd-sbi/rmi-core.c:132 rmi_cpuid_read() warn: bitwise OR is zero '0xffffffff00000000 & 0xffff'
> drivers/misc/amd-sbi/rmi-core.c:132 rmi_cpuid_read() warn: potential integer overflow from user 'msg->cpu_in_out << 32'
> drivers/misc/amd-sbi/rmi-core.c:213 rmi_mca_msr_read() warn: bitwise OR is zero '0xffffffff00000000 & 0xffff'
> drivers/misc/amd-sbi/rmi-core.c:213 rmi_mca_msr_read() warn: potential integer overflow from user 'msg->mcamsr_in_out << 32'
> 
> CPUID thread data from input is available at byte 4 & 5, this
> patch fixes to copy the user data correctly in the argument.
> 
> Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> Closes: https://lore.kernel.org/all/aDVyO8ByVsceybk9@stanley.mountain/
> Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@....com>
> Signed-off-by: Akshay Gupta <akshay.gupta@....com>
> ---
> Changes from v1:
>  - Split patch as per Greg's suggestion
> 
>  drivers/misc/amd-sbi/rmi-core.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/misc/amd-sbi/rmi-core.c b/drivers/misc/amd-sbi/rmi-core.c
> index b653a21a909e..3570f3b269a9 100644
> --- a/drivers/misc/amd-sbi/rmi-core.c
> +++ b/drivers/misc/amd-sbi/rmi-core.c
> @@ -42,7 +42,6 @@
>  #define RD_MCA_CMD	0x86
>  
>  /* CPUID MCAMSR mask & index */
> -#define CPUID_MCA_THRD_MASK	GENMASK(15, 0)
>  #define CPUID_MCA_THRD_INDEX	32
>  #define CPUID_MCA_FUNC_MASK	GENMASK(31, 0)
>  #define CPUID_EXT_FUNC_INDEX	56
> @@ -129,7 +128,7 @@ static int rmi_cpuid_read(struct sbrmi_data *data,
>  		goto exit_unlock;
>  	}
>  
> -	thread = msg->cpu_in_out << CPUID_MCA_THRD_INDEX & CPUID_MCA_THRD_MASK;
> +	thread = msg->cpu_in_out >> CPUID_MCA_THRD_INDEX;

So this takes a u64 and just moves it over 32 bits and then does what?
I guess it makes sense but how did the original code ever work at all?

>  
>  	/* Thread > 127, Thread128 CS register, 1'b1 needs to be set to 1 */
>  	if (thread > 127) {
> @@ -210,7 +209,7 @@ static int rmi_mca_msr_read(struct sbrmi_data *data,
>  		goto exit_unlock;
>  	}
>  
> -	thread = msg->mcamsr_in_out << CPUID_MCA_THRD_INDEX & CPUID_MCA_THRD_MASK;
> +	thread = msg->mcamsr_in_out >> CPUID_MCA_THRD_INDEX;

Same here, was the original code just wrong?

And if this wrong, should this get a fixes: line?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ