Bugzilla – Bug 1213271
VUL-0: CVE-2023-3640: kernel-source,kernel-source-rt,kernel-source-azure: x86/mm: per-cpu entry area leak via init_cea_offsets()
Last modified: 2024-05-22 11:46:02 UTC
CVE-2023-3640 A flaw in the Linux Kernel found. First, based on the previous similar CVE 2023-0597, the 'Randomize per-cpu entry area' feature was implemented in /arch/x86/mm/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. In systems with KPTI enabled, only a minimal amount of kernel virtual memory is mapped for users, such as exception/system call entry handlers and any other necessary content for user-to-kernel transitions. However, discovered that the per-cpu entry area was also mapped to user space. As a result, the prefetchnta and prefetcht2 instructions are still effective, allowing us to leak the per-cpu entry area by conducting time-based attacks using prefetch instructions in the address range of 0xfffffe0000000000-0xfffffefffffff000. In fact, due to the insufficiently large address offset range and the step size of 0x3b000, the cpu entry area can be obtained within one or two minutes. Essentially, this is a CPU-level address leak vulnerability that affects the vast majority of Intel CPUs (possibly AMD CPUs as well), due to the inability to resolve the issues introduced by KPTI (Kernel Page Table Isolation). Reference: TODO add link to the patch when becomes available. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 https://bugzilla.redhat.com/show_bug.cgi?id=2217523
Nik, are you aware of any developments here?
Nope
This security issue only refers to leaks of pointers in the per CPU area. This area does not contain userdata or sensitive data, but pointers into other areas of the kernel. So no user sensitive information can be leaked by this issue. There is also no code execution possible directly due to this leak, it can only be used to bypass protection measure like KASLR.
I spoke with Thomas Gleixner and the conclusion is -EWONTFIX, basically so long as there is a mapping there is an attack vector: > <tglx> but yes, you can still do speculative attacks on it because it is mapped into user space > <tglx> you can do that on the entry code too > <tglx> but as long as there is a mapping there is an attack vector > <tglx> again > <tglx> KASLR is not defendable against a local host attack on x86 Looking at the fix for the previous CVE: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80 The init_cea_offsets already randomizes the placement of the percpu areas within the 512g range.
(In reply to Nikolay Borisov from comment #16) > I spoke with Thomas Gleixner and the conclusion is -EWONTFIX, basically so > long as there is a mapping there is an attack vector: > > > <tglx> but yes, you can still do speculative attacks on it because it is mapped into user space > > <tglx> you can do that on the entry code too > > <tglx> but as long as there is a mapping there is an attack vector > > <tglx> again > > <tglx> KASLR is not defendable against a local host attack on x86 > > Looking at the fix for the previous CVE: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80 > > The init_cea_offsets already randomizes the placement of the percpu areas > within the 512g range. And PeterZ's opinion: > <peterz> everybody that thinks kaslr is any good for local attacks is sniffing glue > <peterz> nist should just stop accepting CVEs against linux Given all of this I'd say this CVE is a way for someone to try and gain some fame aka security theatre....
I am not sure how to close this bug or if we want to keep it open for next few years. Anyway: + The comment #14 describes quite well that the risk is pretty low. Also it affects "only" Meltdown'd CPUs. + The comment #16 suggests that the risk has been lowered even more by randomizing the per_cpu area. + The comment #16 and comment #17 and comment #18 shows that the key upstream people do not consider it worth an effort. Is this enough to dispute the CVE, please?
I guess it is clear by now we aren't going to fix this. So I'm reassigning back to security team to decide whether we should close as WONTFIX or dispute the CVE...
We agreed to close this as WONTFIX