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-next>] [day] [month] [year] [list]
Date: Thu, 23 May 2024 14:14:57 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org,
 linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: CVE-2024-35802: x86/sev: Fix position dependent variable
 references in startup code



On 17.05.24 г. 16:23 ч., Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> x86/sev: Fix position dependent variable references in startup code
> 
> The early startup code executes from a 1:1 mapping of memory, which
> differs from the mapping that the code was linked and/or relocated to
> run at. The latter mapping is not active yet at this point, and so
> symbol references that rely on it will fault.
> 
> Given that the core kernel is built without -fPIC, symbol references are
> typically emitted as absolute, and so any such references occuring in
> the early startup code will therefore crash the kernel.
> 
> While an attempt was made to work around this for the early SEV/SME
> startup code, by forcing RIP-relative addressing for certain global
> SEV/SME variables via inline assembly (see snp_cpuid_get_table() for
> example), RIP-relative addressing must be pervasively enforced for
> SEV/SME global variables when accessed prior to page table fixups.
> 
> __startup_64() already handles this issue for select non-SEV/SME global
> variables using fixup_pointer(), which adjusts the pointer relative to a
> `physaddr` argument. To avoid having to pass around this `physaddr`
> argument across all functions needing to apply pointer fixups, introduce
> a macro RIP_RELATIVE_REF() which generates a RIP-relative reference to
> a given global variable. It is used where necessary to force
> RIP-relative accesses to global variables.
> 
> For backporting purposes, this patch makes no attempt at cleaning up
> other occurrences of this pattern, involving either inline asm or
> fixup_pointer(). Those will be addressed later.
> 
>    [ bp: Call it "rip_rel_ref" everywhere like other code shortens
>      "rIP-relative reference" and make the asm wrapper __always_inline. ]
> 
> The Linux kernel CVE team has assigned CVE-2024-35802 to this issue.


I'd like to dispute this CVE since it doesn't constitute a security 
related bug. Sure, it might crash a SEV guest during boot but it doesn't 
constitute a security issue per-se.



> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Fixed in 6.1.84 with commit fe272b61506b
> 	Fixed in 6.6.24 with commit 0982fd6bf0b8
> 	Fixed in 6.7.12 with commit 66fa3fcb474b
> 	Fixed in 6.8.3 with commit 954a4a878144
> 	Fixed in 6.9 with commit 1c811d403afd
> 
> Please see https://www.kernel.org for a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2024-35802
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	arch/x86/coco/core.c
> 	arch/x86/include/asm/asm.h
> 	arch/x86/include/asm/coco.h
> 	arch/x86/include/asm/mem_encrypt.h
> 	arch/x86/kernel/sev-shared.c
> 	arch/x86/kernel/sev.c
> 	arch/x86/mm/mem_encrypt_identity.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/fe272b61506bb1534922ef07aa165fd3c37a6a90
> 	https://git.kernel.org/stable/c/0982fd6bf0b822876f2e93ec782c4c28a3f85535
> 	https://git.kernel.org/stable/c/66fa3fcb474b2b892fe42d455a6f7ec5aaa98fb9
> 	https://git.kernel.org/stable/c/954a4a87814465ad61cc97c1cd3de1525baaaf07
> 	https://git.kernel.org/stable/c/1c811d403afd73f04bde82b83b24c754011bd0e8

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ