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: <062eb8bd-3d98-4a0a-baf4-8f59b7643041@citrix.com>
Date: Mon, 26 Jan 2026 19:39:51 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Ryusuke Konishi <konishi.ryusuke@...il.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Marco Elver <elver@...gle.com>,
 LKML <linux-kernel@...r.kernel.org>, Alexander Potapenko
 <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
 Jann Horn <jannh@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [REGRESSION] x86_32 boot hang in 6.19-rc7 caused by b505f1944535
 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")

On 26/01/2026 7:07 pm, Ryusuke Konishi wrote:
> Hi All,
>
> I am reporting a boot regression in v6.19-rc7 on an x86_32
> environment. The kernel hangs immediately after "Booting the kernel"
> and does not produce any early console output.
>
> A git bisect identified the following commit as the first bad commit:
> b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")
>
> Environment and Config:
> - Guest Arch: x86_32  (one of my test VMs)
> - Memory Config: # CONFIG_X86_PAE is not set
> - KFENCE Config: CONFIG_KFENCE=y
> - Host/Hypervisor: x86_64 host running KVM
>
> The system fails to boot at a very early stage. I have confirmed that
> reverting commit b505f1944535 on top of v6.19-rc7 completely resolves
> the issue, and the kernel boots normally.
>
> Could you please verify if this change is compatible with x86_32
> (non-PAE) configurations?
> I am happy to provide my full .config or test any potential fixes.

Hmm.  To start with, does this fix the crash?

diff --git a/arch/x86/include/asm/kfence.h b/arch/x86/include/asm/kfence.h
index acf9ffa1a171..2fe454722e54 100644
--- a/arch/x86/include/asm/kfence.h
+++ b/arch/x86/include/asm/kfence.h
@@ -67,8 +67,6 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect)
         * If the page was protected (non-present) and we're making it
         * present, there is no need to flush the TLB at all.
         */
-       if (!protect)
-               return true;
 
        /*
         * We need to avoid IPIs, as we may get KFENCE allocations or faults



Re-reading, I can't spot anything obvious.

Architecturally, x86 explicitly does not need a TLB flush when turning a
non-present mapping present, and it's strictly 4k leaf mappings we're
handling here.

I wonder if something else is missing a flush, and was being covered by
this.

~Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ