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. ... /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. • 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. ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: aardvark: solucionó el pánico del kernel durante la transferencia de PIO. ... 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 Pero la causa real fue el hecho de que durante el reentrenamiento del enlace o después de un evento de caída del enlace, la transferencia de PIO puede tardar más tiempo, hasta 1,44 segundos hasta que se agote el tiempo de espera. • 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 ? ... 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. ... En SEV, la memoria marcada con el atributo EFI_MEMORY_RUNTIME debe ser asignada cifrada por Linux; de lo contrario, el kernel podría fallar en el arranque como se muestra a continuación: EFI Variables Facility v0.08 2004-May-17 falla de protección general, probablemente para la dirección no canónica 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 No contaminado 5.12.4-2-default #1 openSUSE Tumbleweed Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 02 /06/2015 RIP: 0010:efi_mokvar_entry_next [...] • 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. ... 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. • 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. ... 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. • 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 •