linux-kernel - Re: [x86/cpufeature] 7b5e74e637: BUG: unable to handle kernel paging request at 6b636170

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 25 May 2016 08:28:15 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Jones <davej@...emonkey.org.uk>,
	kernel test robot <fengguang.wu@...el.com>,
	Borislav Petkov <bp@...e.de>, LKP <lkp@...org>,
	oprofile-list@...ts.sf.net, linux-kernel@...r.kernel.org,
	wfg@...ux.intel.com
Subject: Re: [x86/cpufeature] 7b5e74e637:  BUG: unable to handle kernel
 paging request at 6b636170


* Dave Jones <davej@...emonkey.org.uk> wrote:

> On Wed, May 25, 2016 at 03:58:10AM +0800, kernel test robot wrote:
>  
>  > 0day kernel testing robot got the below dmesg and the first bad commit is
>  > 
>  > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>  > 
>  > commit 7b5e74e637e4a977c7cf40fd7de332f60b68180e
>  > Author:     Borislav Petkov <bp@...e.de>
>  > AuthorDate: Tue Mar 29 17:41:54 2016 +0200
>  > Commit:     Ingo Molnar <mingo@...nel.org>
>  > CommitDate: Thu Mar 31 13:33:17 2016 +0200
>  > 
>  >     x86/cpufeature: Remove cpu_has_arch_perfmon
>  >     
>  >     Use boot_cpu_has() instead.
> 
> This seem an unlikely candidate given...
> 
>  > [    1.914984] random: trinity urandom read with 25 bits of entropy available
>  > [    8.542178] random: nonblocking pool is initialized
>  > [   11.939833] sock: process `trinity-main' is using obsolete setsockopt SO_BSDCOMPAT
>  > [   12.349890] BUG: unable to handle kernel paging request at 6b636170
>  > [   12.349895] IP: [<c108154b>] perf_prepare_sample+0x7d/0x263
> 
> The trace is more related to perf.

Also, 7b5e74e637e4a appears to be pretty much a provable NOP, it should not change 
a single byte in the kernel image, as it replaces a macro use:

-#define cpu_has_arch_perfmon   boot_cpu_has(X86_FEATURE_ARCH_PERFMON)

... with open-coded expressions of the same.

Thanks,

	Ingo