[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rk37tcrlpnziymqpj72f2glu4kh7v5pgxnurhnmuwhwkyuyfpm@iqvzvuicy3xu>
Date: Tue, 5 Nov 2024 16:20:27 +0000
From: Karan Sanghavi <karansanghvi98@...il.com>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: Yazen Ghannam <Yazen.Ghannam@....com>, Tony Luck <tony.luck@...el.com>,
Borislav Petkov <bp@...en8.de>, linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RAS/AMD/ATL: Fix unintended sign extension issue from
coverity
On Mon, Nov 04, 2024 at 02:51:56PM -0700, Shuah Khan wrote:
> On 11/4/24 11:34, Karan Sanghavi wrote:
> > Explicit cast pc to u32 to avoid sign extension while left shift
> >
> > Issue reported by coverity with CID: 1593397
> >
> > Signed-off-by: Karan Sanghavi <karansanghvi98@...il.com>
> > ---
> > Coverity Link:
> > https://scan7.scan.coverity.com/#/project-view/51975/11354?selectedIssue=1593397
>
> Please include the coverity message instead of this link so
> reviewers without coverity accounts can see the report.
>
sure will keep it in mind.
> > ---
> > drivers/ras/amd/atl/umc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/ras/amd/atl/umc.c b/drivers/ras/amd/atl/umc.c
> > index dc8aa12f63c8..916c867faaf8 100644
> > --- a/drivers/ras/amd/atl/umc.c
> > +++ b/drivers/ras/amd/atl/umc.c
> > @@ -293,7 +293,7 @@ static unsigned long convert_dram_to_norm_addr_mi300(unsigned long addr)
> > }
> > /* PC bit */
> > - addr |= pc << bit_shifts.pc;
> > + addr |= (u32)pc << bit_shifts.pc;
>
> How did you determine this is the right fix and how did
> test this change?
>
#define ADDR_SEL_2_CHAN GENMASK(15, 12)
bit_shifts.pc = 5 + FIELD_GET(ADDR_SEL_2_CHAN, temp);
After reviewing the code, I found that bit_shifts.pc can reach a maximum value of 20.
Left-shifting a u16 pc by this amount results in an implicit promotion to an int64_t,
which can cause sign extension and lead to unintended negative values.
To avoid this, casting to a larger data type (such as u64) woulbe be most
appropriate solution here.
Also,using u64 would be more appropriate rather than u32.
Should I send a new patch with u64?
> > /* SID bits */
> > for (i = 0; i < NUM_SID_BITS; i++) {
> >
> > ---
> > base-commit: 81983758430957d9a5cb3333fe324fd70cf63e7e
> > change-id: 20241104-coverity1593397signextension-78c9b2c21d51
> >
> > Best regards,
>
> thanks,
> -- Shuah
Thank you,
Karan.
Powered by blists - more mailing lists