linux-kernel - Re: [patch 30/41] ACPI EC: Fix regression due to use of uninitialized variable

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: <200902051606.05657.trenn@suse.de>
Date:	Thu, 5 Feb 2009 16:06:02 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org, stable@...nel.org,
	Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Domenico Andreoli <cavokz@...il.com>, Willy Tarreau <w@....eu>,
	Rodrigo Rubira Branco <rbranco@...checkpoint.com>,
	Jake Edge <jake@....net>, Eugene Teo <eteo@...hat.com>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	Len Brown <len.brown@...el.com>
Subject: Re: [patch 30/41] ACPI EC: Fix regression due to use of uninitialized variable

On Thursday 05 February 2009 09:08:42 Thomas Renninger wrote:
> Hi,
> 
> On Wednesday 04 February 2009 19:46:48 Greg KH wrote:
> > 2.6.27-stable review patch.  If anyone has any objections, please let us
> > know.
> Does this one patch cleanly in 2.6.27-stable?
> I had it on my list, but this seem to have been introduced after
> 2.6.27 and I thought I removed this one again?
> Or this is a follow up of another fix that should go in?
Yes this got in by another patch.
The huge "make ACPI integer 64 bit aware" one. Which looked like
it could fix really nasty bugs and is safe due to only long to long long
conversions. But maybe this wasn't such a good idea, as exported
kernel functions change from long to long long...

    Thomas
> 
>    Thomas
> 
> > ------------------
> >
> > From: Alexey Starikovskiy <astarikovskiy@...e.de>
> >
> > commit d21cf3c16b1191f3154a51e0b20c82bf851cc553 upstream.
> >
> > breakage introduced by following patch
> > commit 27663c5855b10af9ec67bc7dfba001426ba21222
> > Author: Matthew Wilcox <willy@...ux.intel.com>
> > Date:   Fri Oct 10 02:22:59 2008 -0400
> >
> > acpi_evaluate_integer() does not clear passed variable if
> > there is an error at evaluation.
> > So if we ignore error, we must supply initialized variable.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=11917
> >
> > Signed-off-by: Alexey Starikovskiy <astarikovskiy@...e.de>
> > Tested-by: Alan Jenkins <alan-jenkins@...fmail.co.uk>
> > Signed-off-by: Len Brown <len.brown@...el.com>
> > Cc: Thomas Renninger <trenn@...e.de>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> >
> > ---
> >  drivers/acpi/ec.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -769,7 +769,7 @@ static acpi_status
> >  ec_parse_device(acpi_handle handle, u32 Level, void *context, void
> > **retval) {
> >  	acpi_status status;
> > -	unsigned long long tmp;
> > +	unsigned long long tmp = 0;
> >
> >  	struct acpi_ec *ec = context;
> >  	status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > @@ -784,6 +784,7 @@ ec_parse_device(acpi_handle handle, u32
> >  		return status;
> >  	ec->gpe = tmp;
> >  	/* Use the global lock for all EC transactions? */
> > +	tmp = 0;
> >  	acpi_evaluate_integer(handle, "_GLK", NULL, &tmp);
> >  	ec->global_lock = tmp;
> >  	ec->handle = handle;
> 
> 

--
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/