linux-kernel - Re: [PATCH] ASoC: soc-dapm: Fix comparison of pointers

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] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2014 14:17:14 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:	Takashi Iwai <tiwai@...e.de>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: soc-dapm: Fix comparison of pointers

On Fri, Dec 12, 2014 at 02:43:27PM +0100, Rasmus Villemoes wrote:
> On Fri, Dec 12 2014, Mark Brown <broonie@...nel.org> wrote:

> > If we're worrying about standards conformance type stuff here this is
> > also buggy since it's out of spec to compare pointers that are not part
> > of the same array like this.  Casting to uintptr_t is a better fix here.

> I'm not worrying about standards conformance. Casting pointers to and
> from [unsigned] long is done everywhere in the kernel, and that's
> fine. But subtracting ints or longs and using the sign of the result for
> comparison is simply wrong. See acbbe6fbb2 (kcmp: fix standard
> comparison bug) for the long story. In this case the narrowing (when
> BITS_PER_LONG==64) of the result from long to int just makes it even
> more wrong.

*sigh*  If that's what you meant you should've said so in your commit
log since that's distinctly non-obvious.  In any case, regardless of why
you originally wanted to do this the fact remains that your new version
is out of spec.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)