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>] [day] [month] [year] [list]
Date:	Tue, 29 May 2012 18:26:25 -0700 (PDT)
From:	Zhenzhong Duan <zhenzhong.duan@...cle.com>
To:	<yinghai@...nel.org>
Cc:	<mingo@...hat.com>, <x86@...nel.org>, <tglx@...utronix.de>,
	<joe.jin@...cle.com>, <linux-kernel@...r.kernel.org>,
	<ethan.zhao@...cle.com>, <hpa@...or.com>
Subject: 答复: Re: [PATCH] Fix an overflow in range_to_mtrr func


----- yinghai@...nel.org 写道:

> On Mon, May 28, 2012 at 5:29 AM, Zhenzhong Duan
> <zhenzhong.duan@...cle.com> wrote:
> > When boot x86_64 kernel on sun G5+ with 4T mem, see an overflow in
> mtrr cleanup as below.
> >
> > *BAD*gran_size: 2G      chunk_size: 2G  num_reg: 10     lose cover
> RAM:
> > -18014398505283592M
> >
> > This is because 1<<31 sign extended.
> > Use explicit type conversion to force a 64bit constant to fix it.
> > Useful for mem larger than or equal to 4T.
> >
> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@...cle.com>
> > ---
> >  arch/x86/kernel/cpu/mtrr/cleanup.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
> b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > index ac140c7..853a4c6 100644
> > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > @@ -266,7 +266,7 @@ range_to_mtrr(unsigned int reg, unsigned long
> range_startk,
> >                if (align > max_align)
> >                        align = max_align;
> >
> > -               sizek = 1 << align;
> > +               sizek = (unsigned long)1 << align;
> 
> how about
> 
>             sizek = 1UL << align;
> 
> 
> >                if (debug_print) {
> >                        char start_factor = 'K', size_factor = 'K';
> >                        unsigned long start_base, size_base;
> > --
> > 1.7.3
> >
Yes, this looks more clean although same compiling result. Should i resend it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists