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:   Thu, 17 Nov 2022 14:58:37 +0100
From:   Marco Elver <elver@...gle.com>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>
Cc:     kasan-dev <kasan-dev@...glegroups.com>, X86 ML <x86@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, regressions@...ts.linux.dev,
        lkft-triage@...ts.linaro.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>
Subject: Re: WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/kfence.h:46
 kfence_protect

On Thu, Nov 17, 2022 at 05:01PM +0530, Naresh Kamboju wrote:
> Kunit test cases failed and found warnings while booting Linux next
> version 6.1.0-rc5-next-20221117 on qemu-x86_64 [1].
> 
> It was working on Linux next-20221116 tag.
> 
> [    0.663761] WARNING: CPU: 0 PID: 0 at
> arch/x86/include/asm/kfence.h:46 kfence_protect+0x7b/0x120
> [    0.664033] WARNING: CPU: 0 PID: 0 at mm/kfence/core.c:234
> kfence_protect+0x7d/0x120
> [    0.664465] kfence: kfence_init failed
> 
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
[...]
> [    0.663758] ------------[ cut here ]------------
> [    0.663761] WARNING: CPU: 0 PID: 0 at
> arch/x86/include/asm/kfence.h:46 kfence_protect+0x7b/0x120
[...]
> [    0.664465] kfence: kfence_init failed
> 
> metadata:
>   git_ref: master
>   git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
>   git_sha: af37ad1e01c72483c4ee8453d9d9bac95d35f023
>   git_describe: next-20221117
>   kernel_version: 6.1.0-rc5
>   kernel-config: https://builds.tuxbuild.com/2Hfb6n1z0frt4iBlIvqUzjMHiLm/config
>   build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/697483979
>   artifact-location: https://builds.tuxbuild.com/2Hfb6n1z0frt4iBlIvqUzjMHiLm
>   toolchain: gcc-11

I bisected this to:

	commit 127960a05548ea699a95791669e8112552eb2452
	Author: Peter Zijlstra <peterz@...radead.org>
	Date:   Thu Nov 10 13:33:57 2022 +0100

	    x86/mm: Inhibit _PAGE_NX changes from cpa_process_alias()

	    There is a cludge in change_page_attr_set_clr() that inhibits
	    propagating NX changes to the aliases (directmap and highmap) -- this
	    is a cludge twofold:

	     - it also inhibits the primary checks in __change_page_attr();
	     - it hard depends on single bit changes.

	    The introduction of set_memory_rox() triggered this last issue for
	    clearing both _PAGE_RW and _PAGE_NX.

	    Explicitly ignore _PAGE_NX in cpa_process_alias() instead.

	    Fixes: b38994948567 ("x86/mm: Implement native set_memory_rox()")
	    Reported-by: kernel test robot <oliver.sang@...el.com>
	    Debugged-by: Dave Hansen <dave.hansen@...el.com>
	    Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
	    Link: https://lkml.kernel.org/r/20221110125544.594991716%40infradead.org

A simple revert of this commit fixes the issue.

Since all this seems to be about set_memory_rox(), and this is a fix
commit, the fix itself missed something?

Thanks,
-- Marco

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ