linux-kernel - Re: 3.13: <module> disagrees about version of symbol <symbol>

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:	Wed, 09 Apr 2014 20:01:02 +0200
From:	Thomas Bächler <thomas@...hlinux.org>
To:	Matt Fleming <matt@...sole-pimps.org>
CC:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	matt.fleming@...el.com, ak@...ux.intel.com,
	viro@...iv.linux.org.uk, geert@...ux-m68k.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, tpowa@...hlinux.org, hpa@...or.com
Subject: Re: 3.13: <module> disagrees about version of symbol <symbol>

Am 09.04.2014 10:30, schrieb Thomas Bächler:
> Am 09.04.2014 10:25, schrieb Matt Fleming:
>> On Tue, 08 Apr, at 10:04:48PM, Thomas Bächler wrote:
>>>
>>> Hello again Matt,
>>>
>>> with linux.git master, I cannot reproduce the problem at all (with or
>>> without your patch). In fact, all the 0x0 CRCs on symbols are gone, and
>>> those were the symbols that were broken after all.
>>>
>>> FWIW, with your patch the kernel still boots.
>>  
>> Could you try this version? It's against v3.14,
> 
> I'll do that tonight and report back (now + ~10 hours).

Hello again Matt,

that patch seems to help. Thank you so much.

(I am going to apply this patch and backport dc53324060, too, so
everything should be in order then.)

Regards
Thomas

> In the meantime, I figured out which commit fixed the 0x00000000 symbol
> CRCs in 3.14+, making this bug invisible - it was
> dc53324060f324e8af6867f57bf4891c13c6ef18 in the Linus tree.



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