Bug 1213271 (CVE-2023-3640)

Summary:	VUL-0: CVE-2023-3640: kernel-source,kernel-source-rt,kernel-source-azure: x86/mm: per-cpu entry area leak via init_cea_offsets()
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Carlos López <carlos.lopez>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	RESOLVED WONTFIX	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	Andreas.Stieger, gianluca.gabrielli, jack, jdelvare, meissner, mhocko, mkoutny, pmladek, security-team
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://smash.suse.de/issue/372250/
See Also:	https://bugzilla.suse.com/show_bug.cgi?id=1207845
Whiteboard:	CVSSv3.1:SUSE:CVE-2023-3640:5.5:(AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Found By:	Security Response Team	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Carlos López 2023-07-13 06:37:50 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

Comment 2 Jan Kara 2023-08-31 12:03:08 UTC

Nik, are you aware of any developments here?

Comment 3 Nikolay Borisov 2023-09-04 07:27:32 UTC

Nope

Comment 11 Marcus Meissner 2023-10-15 09:05:28 UTC

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.

Comment 16 Nikolay Borisov 2023-11-02 09:00:20 UTC

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.

Comment 17 Nikolay Borisov 2023-11-02 09:39:27 UTC

(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....

Comment 20 Petr Mladek 2023-11-30 15:10:00 UTC

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?

Comment 23 Jan Kara 2024-02-02 11:06:41 UTC

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...

Comment 24 Gianluca Gabrielli 2024-05-20 10:42:50 UTC

We agreed to close this as WONTFIX