linux-kernel - Re: [PATCH v3 1/2] misc: amd-sbi: Address potential integer overflow issue reported in smatch

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: <ca4fe6d8-4a93-4b44-95d3-3e208f875f87@amd.com>
Date: Tue, 1 Jul 2025 14:45:40 +0530
From: "Gupta, Akshay" <Akshay.Gupta@....com>
To: Greg KH <gregkh@...uxfoundation.org>
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 7/1/2025 11:19 AM, Greg KH wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> 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?

CPUID register data(leaf and sub-leaf) is provided to user for the input 
thread.

Previously data is return only for thread 0 and not for other threads.

>>        /* 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?
I will update the commit message to include the commit ID and the line.
>
> thanks,
>
> greg k-h