linux-kernel - Re: [patch] amd64_edac: shift wrapping issue in f1x_get_norm_dct

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:	Thu, 21 Jan 2016 13:32:05 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Dan Carpenter <dan.carpenter@...cle.com>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>
Cc:	Doug Thompson <dougthompson@...ssion.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [patch] amd64_edac: shift wrapping issue in
 f1x_get_norm_dct_addr()

On Wed, Jan 20, 2016 at 12:54:51PM +0300, Dan Carpenter wrote:
> dct_sel_base_off is declared as a u64 but we're only using the lower 32
> bits because of a shift wrapping bug.
> 
> Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> ---
> Static checker stuff.  Not tested.
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 9eee13e..d87a475 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -1452,7 +1452,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
>  	u64 chan_off;
>  	u64 dram_base		= get_dram_base(pvt, range);
>  	u64 hole_off		= f10_dhar_offset(pvt);
> -	u64 dct_sel_base_off	= (pvt->dct_sel_hi & 0xFFFFFC00) << 16;
> +	u64 dct_sel_base_off	= (u64)(pvt->dct_sel_hi & 0xFFFFFC00) << 16;

Good catch.

So this could possibly give us the wrong channel address and thus not
find the CS row. Hmm, so on my boxes, DctSelBaseOffset[47:26] is not big
enough so that its high 16-bits are 0 and truncation doesn't hurt there.

@Aravind: do you have a box with

setpci -s 18.2 0x114.l

bits [31:16] not 0?

If so, you might want to run with and without this fix above as it
should fix system address to CS row mapping.

Anyway, applied and tagged for stable.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.