CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47094 – KVM: x86/mmu: Don't advance iterator after restart due to yielding
https://notcve.org/view.php?id=CVE-2021-47094
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Don't advance iterator after restart due to yielding After dropping mmu_lock in the TDP MMU, restart the iterator during tdp_iter_next() and do not advance the iterator. Advancing the iterator results in skipping the top-level SPTE and all its children, which is fatal if any of the skipped SPTEs were not visited before yielding. When zapping all SPTEs, i.e. when min_level == root_level, restarting the iter and then invoking tdp_iter_next() is always fatal if the current gfn has as a valid SPTE, as advancing the iterator results in try_step_side() skipping the current gfn, which wasn't visited before yielding. Sprinkle WARNs on iter->yielded being true in various helpers that are often used in conjunction with yielding, and tag the helper with __must_check to reduce the probabily of improper usage. Failing to zap a top-level SPTE manifests in one of two ways. If a valid SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(), the shadow page will be leaked and KVM will WARN accordingly. WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm] RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm] Call Trace: <TASK> kvm_arch_destroy_vm+0x130/0x1b0 [kvm] kvm_destroy_vm+0x162/0x2a0 [kvm] kvm_vcpu_release+0x34/0x60 [kvm] __fput+0x82/0x240 task_work_run+0x5c/0x90 do_exit+0x364/0xa10 ? futex_unqueue+0x38/0x60 do_group_exit+0x33/0xa0 get_signal+0x155/0x850 arch_do_signal_or_restart+0xed/0x750 exit_to_user_mode_prepare+0xc5/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of marking a struct page as dirty/accessed after it has been put back on the free list. This directly triggers a WARN due to encountering a page with page_count() == 0, but it can also lead to data corruption and additional errors in the kernel. WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../.. • https://git.kernel.org/stable/c/faaf05b00aecdb347ffd1d763d024394ec0329f8 https://git.kernel.org/stable/c/3c7a18440638b1c5a4645e2de1670cee32df7307 https://git.kernel.org/stable/c/d884eefd75cc54887bc2e9e724207443525dfb2c https://git.kernel.org/stable/c/3a0f64de479cae75effb630a2e0a237ca0d0623c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47093 – platform/x86: intel_pmc_core: fix memleak on registration failure
https://notcve.org/view.php?id=CVE-2021-47093
In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel_pmc_core: fix memleak on registration failure In case device registration fails during module initialisation, the platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: intel_pmc_core: corrige memleak en falla de registro En caso de que el registro del dispositivo falle durante la inicialización del módulo, la estructura del dispositivo de la plataforma debe liberarse usando platform_device_put() para liberar adecuadamente todos los recursos ( por ejemplo, el nombre del dispositivo). • https://git.kernel.org/stable/c/938835aa903ae19ad62805134f79bbcf20fc3bea https://git.kernel.org/stable/c/7a37f2e370699e2feca3dca6c8178c71ceee7e8a https://git.kernel.org/stable/c/9ca1324755f1f8629a370af5cc315b175331f5d1 https://git.kernel.org/stable/c/26a8b09437804fabfb1db080d676b96c0de68e7c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47092 – KVM: VMX: Always clear vmx->fail on emulation_required
https://notcve.org/view.php?id=CVE-2021-47092
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Always clear vmx->fail on emulation_required Revert a relatively recent change that set vmx->fail if the vCPU is in L2 and emulation_required is true, as that behavior is completely bogus. Setting vmx->fail and synthesizing a VM-Exit is contradictory and wrong: (a) it's impossible to have both a VM-Fail and VM-Exit (b) vmcs.EXIT_REASON is not modified on VM-Fail (c) emulation_required refers to guest state and guest state checks are always VM-Exits, not VM-Fails. For KVM specifically, emulation_required is handled before nested exits in __vmx_handle_exit(), thus setting vmx->fail has no immediate effect, i.e. KVM calls into handle_invalid_guest_state() and vmx->fail is ignored. Setting vmx->fail can ultimately result in a WARN in nested_vmx_vmexit() firing when tearing down the VM as KVM never expects vmx->fail to be set when L2 is active, KVM always reflects those errors into L1. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548 nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Modules linked in: CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Code: <0f> 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80 Call Trace: vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline] nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330 vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799 kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989 kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline] kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline] kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220 kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../.. • https://git.kernel.org/stable/c/c8607e4a086fae05efe5bffb47c5199c65e7216e https://git.kernel.org/stable/c/e4e4e7cb229821cd215031abc47efdab5486a67c https://git.kernel.org/stable/c/a80dfc025924024d2c61a4c1b8ef62b2fce76a04 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47091 – mac80211: fix locking in ieee80211_start_ap error path
https://notcve.org/view.php?id=CVE-2021-47091
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix locking in ieee80211_start_ap error path We need to hold the local->mtx to release the channel context, as even encoded by the lockdep_assert_held() there. Fix it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: corrige el bloqueo en la ruta de error ieee80211_start_ap Necesitamos mantener local->mtx para liberar el contexto del canal, incluso codificado por lockdep_assert_held() allí. Arreglalo. • https://git.kernel.org/stable/c/295b02c4be74bebf988593b8322369513fcecf68 https://git.kernel.org/stable/c/ac61b9c6c0549aaeb98194cf429d93c41bfe5f79 https://git.kernel.org/stable/c/c1d1ec4db5f7264cfc21993e59e8f2dcecf4b44f https://git.kernel.org/stable/c/87a270625a89fc841f1a7e21aae6176543d8385c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47090 – mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
https://notcve.org/view.php?id=CVE-2021-47090
In the Linux kernel, the following vulnerability has been resolved: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page() Hulk Robot reported a panic in put_page_testzero() when testing madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying get_any_page(). This is because we keep MF_COUNT_INCREASED flag in second try but the refcnt is not increased. page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:737! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: release_pages+0x53f/0x840 Call Trace: free_pages_and_swap_cache+0x64/0x80 tlb_flush_mmu+0x6f/0x220 unmap_page_range+0xe6c/0x12c0 unmap_single_vma+0x90/0x170 unmap_vmas+0xc4/0x180 exit_mmap+0xde/0x3a0 mmput+0xa3/0x250 do_exit+0x564/0x1470 do_group_exit+0x3b/0x100 __do_sys_exit_group+0x13/0x20 __x64_sys_exit_group+0x16/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: ---[ end trace e99579b570fe0649 ]--- RIP: 0010:release_pages+0x53f/0x840 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hwpoison: borre MF_COUNT_INCREASED antes de volver a intentar get_any_page() Hulk Robot informó un pánico en put_page_testzero() al probar madvise() con MADV_SOFT_OFFLINE. El ERROR() se activa al volver a intentar get_any_page(). • https://git.kernel.org/stable/c/b94e02822debdf0cc473556aad7dcc859f216653 https://git.kernel.org/stable/c/1f207076740101fed87074a6bc924dbe806f08a5 https://git.kernel.org/stable/c/c691e7575eff76e563b0199c23ec46bd454f43e3 https://git.kernel.org/stable/c/2a57d83c78f889bf3f54eede908d0643c40d5418 •