linux-kernel - Re: [rfc patch] wm8994: range checking issue

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: <20100324143139.GE26453@rakim.wolfsonmicro.main>
Date:	Wed, 24 Mar 2010 14:31:39 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Dan Carpenter <error27@...il.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [rfc patch] wm8994: range checking issue

On Wed, Mar 24, 2010 at 05:06:21PM +0300, Dan Carpenter wrote:
> On Wed, Mar 24, 2010 at 12:59:46PM +0000, Mark Brown wrote:

> > This is caused by confusion with the MAX_CACHED_REGISTER definition in
> > the header.  Best to use that one consistently, I guess - I've got a
> > sneaking suspicion something has gone AWOL in the driver publication
> > process.

> Hm...  That sounds more involved than I anticipated.  I don't have the
> hardware and don't feel comfortable making complicated changes if I
> can't test them.

Not really, it's just a case of picking the value to standardise on for
the size of the array instead of the one you picked.  However, now I
look at it again REG_CACHE_SIZE is the one we want and _MAX_CACHED_REGISTER 
is bitrot which should be removed.

I didn't look as closely as I might due to the extraneous changes for
BUG_ON() I mentioned which meant the patch wouldn't be applied anyway.
Those shouldn't be changed because there's no way anything in the kernel
should be generating a reference to a register which doesn't physically
exist (which is what they check for).

> Can someone else take care of this.

Actually, now I look even more closely there's further issues with the
patch - you're missing the fact that the register cache is only used for
non-volatile registers but all registers beyond the end of the register
cache are treated as volatile.  This means that I'm not convinced there
are any actual problems here, I'm not sure what analysis smatch is doing
but it looks to have generated false positives here.

I'll send a patch for _MAX_CACHED_REGISTER later today.
--
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/