From: "Gupta, Akshay" <Akshay.Gupta@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de,
shyam-sundar.s-k@amd.com, gautham.shenoy@amd.com,
mario.limonciello@amd.com, naveenkrishna.chatradhi@amd.com,
anand.umarji@amd.com, Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH v3 1/2] misc: amd-sbi: Address potential integer overflow issue reported in smatch
Date: Tue, 1 Jul 2025 14:45:40 +0530 [thread overview]
Message-ID: <ca4fe6d8-4a93-4b44-95d3-3e208f875f87@amd.com> (raw)
In-Reply-To: <2025070125-ice-outbreak-3e02@gregkh>
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@linaro.org>
>> Closes: https://lore.kernel.org/all/aDVyO8ByVsceybk9@stanley.mountain/
>> Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
>> Signed-off-by: Akshay Gupta <akshay.gupta@amd.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
prev parent reply other threads:[~2025-07-01 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 5:40 Akshay Gupta
2025-07-01 5:40 ` [PATCH v3 2/2] misc: amd-sbi: Address copy_to/from_user() warning " Akshay Gupta
2025-07-01 5:49 ` Greg KH
2025-07-01 9:16 ` Gupta, Akshay
2025-07-01 5:49 ` [PATCH v3 1/2] misc: amd-sbi: Address potential integer overflow issue " Greg KH
2025-07-01 9:15 ` Gupta, Akshay [this message]
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=ca4fe6d8-4a93-4b44-95d3-3e208f875f87@amd.com \
--to=akshay.gupta@amd.com \
--cc=anand.umarji@amd.com \
--cc=arnd@arndb.de \
--cc=dan.carpenter@linaro.org \
--cc=gautham.shenoy@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=naveenkrishna.chatradhi@amd.com \
--cc=shyam-sundar.s-k@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®