CVSS: 6.6EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47230 – KVM: x86: Immediately reset the MMU context when the SMM flag is cleared
https://notcve.org/view.php?id=CVE-2021-47230
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Immediately reset the MMU context when the SMM flag is cleared Immediately reset the MMU context when the vCPU's SMM flag is cleared so that the SMM flag in the MMU role is always synchronized with the vCPU's flag. If RSM fails (which isn't correctly emulated), KVM will bail without calling post_leave_smm() and leave the MMU in a bad state. The bad MMU role can lead to a NULL pointer dereference when grabbing a shadow page's rmap for a page fault as the initial lookups for the gfn will happen with the vCPU's SMM flag (=0), whereas the rmap lookup will use the shadow page's SMM flag, which comes from the MMU (=1). SMM has an entirely different set of memslots, and so the initial lookup can find a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1). general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline] RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 Code: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000 R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline] mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline] direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline] kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065 vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494 kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x440ce9 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM Restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM de la vCPU para que el indicador SMM en la función MMU esté siempre sincronizado con el indicador de la vCPU. Si RSM falla (que no se emula correctamente), KVM se retirará sin llamar a post_leave_smm() y dejará la MMU en mal estado. • https://git.kernel.org/stable/c/9ec19493fb86d6d5fbf9286b94ff21e56ef66376 https://git.kernel.org/stable/c/cbb425f62df9df7abee4b3f068f7ed6ffc3561e2 https://git.kernel.org/stable/c/669a8866e468fd020d34eb00e08cb41d3774b71b https://git.kernel.org/stable/c/df9a40cfb3be2cbeb1c17bb67c59251ba16630f3 https://git.kernel.org/stable/c/78fcb2c91adfec8ce3a2ba6b4d0dda89f2f4a7c6 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47229 – PCI: aardvark: Fix kernel panic during PIO transfer
https://notcve.org/view.php?id=CVE-2021-47229
In the Linux kernel, the following vulnerability has been resolved: PCI: aardvark: Fix kernel panic during PIO transfer Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError Interrupt To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet. If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out. In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler. Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541 But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet. After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: aardvark: solucionó el pánico del kernel durante la transferencia de PIO. Intentar iniciar una nueva transferencia de PIO escribiendo el valor 0 en el registro PIO_START cuando la transferencia anterior aún no se ha completado (que se indica con el valor 1). en PIO_START) provoca un aborto externo en la CPU, lo que resulta en pánico del kernel: Interrupción de SError en CPU0, código 0xbf000002 - Pánico del kernel de SError - no se sincroniza: Interrupción de SError asincrónica Para evitar el pánico del kernel, es necesario rechazar una nueva transferencia de PIO cuando el anterior aún no ha terminado. • https://git.kernel.org/stable/c/400e6b1860c8be61388d0b77814c53260f96e17a https://git.kernel.org/stable/c/b00a9aaa4be20ad6e3311fb78a485eae0899e89a https://git.kernel.org/stable/c/4c90f90a91d75c3c73dd633827c90e8746d9f54d https://git.kernel.org/stable/c/1a1dbc4473974867fe8c5f195c17b341c8e82867 https://git.kernel.org/stable/c/3d213a4ddf49a860be6e795482c17f87e0c82b2a https://git.kernel.org/stable/c/f18139966d072dab8e4398c95ce955a9742e04f7 •
CVSS: 6.2EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47228 – x86/ioremap: Map EFI-reserved memory as encrypted for SEV
https://notcve.org/view.php?id=CVE-2021-47228
In the Linux kernel, the following vulnerability has been resolved: x86/ioremap: Map EFI-reserved memory as encrypted for SEV Some drivers require memory that is marked as EFI boot services data. In order for this memory to not be re-used by the kernel after ExitBootServices(), efi_mem_reserve() is used to preserve it by inserting a new EFI memory descriptor and marking it with the EFI_MEMORY_RUNTIME attribute. Under SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to be mapped encrypted by Linux, otherwise the kernel might crash at boot like below: EFI Variables Facility v0.08 2004-May-17 general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:efi_mokvar_entry_next [...] Call Trace: efi_mokvar_sysfs_init ? efi_mokvar_table_init do_one_initcall ? __kmalloc kernel_init_freeable ? rest_init kernel_init ret_from_fork Expand the __ioremap_check_other() function to additionally check for this other type of boot data reserved at runtime and indicate that it should be mapped encrypted for an SEV guest. [ bp: Massage commit message. ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/ioremap: asigne la memoria reservada de EFI como cifrada para SEV. • https://git.kernel.org/stable/c/58c909022a5a56cd1d9e89c8c5461fd1f6a27bb5 https://git.kernel.org/stable/c/208bb686e7fa7fff16e8fa78ff0db34aa9acdbd7 https://git.kernel.org/stable/c/b7a05aba39f733ec337c5b952e112dd2dc4fc404 https://git.kernel.org/stable/c/8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47227 – x86/fpu: Prevent state corruption in __fpu__restore_sig()
https://notcve.org/view.php?id=CVE-2021-47227
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Prevent state corruption in __fpu__restore_sig() The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer. Prior to XSAVES support, it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible but not corrupting the state in the first place is more robust. Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms. Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path. [ Changelog polished by Dave Hansen ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/fpu: evita la corrupción del estado en __fpu__restore_sig() La ruta lenta no compactada usa __copy_from_user() y copia todo el búfer del usuario en el búfer del kernel, palabra por palabra. Esto significa que el búfer del kernel ahora puede contener un estado completamente inválido en el que XRSTOR realizará #GP. validar_user_xstate_header() puede detectar parte de esa corrupción, pero eso deja a las personas que llaman la responsabilidad de borrar el búfer. Antes de la compatibilidad con XSAVES, era posible simplemente reinicializar el búfer por completo, pero con los estados del supervisor eso ya no es posible porque la división del código de borrado del búfer lo hacía al revés. • https://git.kernel.org/stable/c/b860eb8dce5906b14e3a7f3c771e0b3d6ef61b94 https://git.kernel.org/stable/c/076f732b16a5bf842686e1b43ab6021a2d98233e https://git.kernel.org/stable/c/ec25ea1f3f05d6f8ee51d1277efea986eafd4f2a https://git.kernel.org/stable/c/484cea4f362e1eeb5c869abbfb5f90eae6421b38 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47226 – x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
https://notcve.org/view.php?id=CVE-2021-47226
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer Both Intel and AMD consider it to be architecturally valid for XRSTOR to fail with #PF but nonetheless change the register state. The actual conditions under which this might occur are unclear [1], but it seems plausible that this might be triggered if one sibling thread unmaps a page and invalidates the shared TLB while another sibling thread is executing XRSTOR on the page in question. __fpu__restore_sig() can execute XRSTOR while the hardware registers are preserved on behalf of a different victim task (using the fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but modify the registers. If this happens, then there is a window in which __fpu__restore_sig() could schedule out and the victim task could schedule back in without reloading its own FPU registers. This would result in part of the FPU state that __fpu__restore_sig() was attempting to load leaking into the victim task's user-visible state. Invalidate preserved FPU registers on XRSTOR failure to prevent this situation from corrupting any state. [1] Frequent readers of the errata lists might imagine "complex microarchitectural conditions". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Invalida el estado de la FPU después de un XRSTOR fallido desde un búfer de usuario. Tanto Intel como AMD consideran que es arquitectónicamente válido que XRSTOR falle con #PF pero aun así cambie el estado del registro. . • https://git.kernel.org/stable/c/1d731e731c4cd7cbd3b1aa295f0932e7610da82f https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb88449296539de0b6817 https://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14 https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953a •