CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47465 – KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
https://notcve.org/view.php?id=CVE-2021-47465
In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stores CR/LR into its callers frame (per the ABI). The problem is that there is no caller frame on the emergency stack. The emergency stack for a given CPU is allocated with: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; So emergency_sp actually points to the first address above the emergency stack allocation for a given CPU, we must not store above it without first decrementing it to create a frame. This is different to the regular kernel stack, paca->kstack, which is initialised to point at an initial frame that is ready to use. idle_kvm_start_guest() stores the backchain, CR and LR all of which write outside the allocation for the emergency stack. It then creates a stack frame and saves the non-volatile registers. • https://git.kernel.org/stable/c/10d91611f426d4bafd2a83d966c36da811b2f7ad https://git.kernel.org/stable/c/80bbb0bc3a0288442f7fe6fc514f4ee1cb06ccb7 https://git.kernel.org/stable/c/fbd724c49bead048ae9fc1a5b7bff2fb3e54f855 https://git.kernel.org/stable/c/6d077c37c4643394b1bae9682da48164fc147ea8 https://git.kernel.org/stable/c/9b4416c5095c20e110c82ae602c254099b83b72f •
CVSS: 7.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47464 – audit: fix possible null-pointer dereference in audit_filter_rules
https://notcve.org/view.php?id=CVE-2021-47464
In the Linux kernel, the following vulnerability has been resolved: audit: fix possible null-pointer dereference in audit_filter_rules Fix possible null-pointer dereference in audit_filter_rules. audit_filter_rules() error: we previously assumed 'ctx' could be null En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: corrige una posible desreferencia de puntero nulo en audit_filter_rules. Corrige una posible desreferencia de puntero nulo en audit_filter_rules. Error audit_filter_rules(): previamente asumimos que 'ctx' podría ser nulo • https://git.kernel.org/stable/c/bf361231c295d92a28ca283ea713f56e93e55796 https://git.kernel.org/stable/c/d6f451f1f60c58d73038c7c3177066f8f084e2a2 https://git.kernel.org/stable/c/16802fa4c33eb1a8efb23f1e93365190e4047d05 https://git.kernel.org/stable/c/4e9e46a700201b4c85081fd478c99c692a9aaa0d https://git.kernel.org/stable/c/6e3ee990c90494561921c756481d0e2125d8b895 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47463 – mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem()
https://notcve.org/view.php?id=CVE-2021-47463
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem() Check for a NULL page->mapping before dereferencing the mapping in page_is_secretmem(), as the page's mapping can be nullified while gup() is running, e.g. by reclaim or truncation. BUG: kernel NULL pointer dereference, address: 0000000000000068 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 4173897 Comm: CPU 3/KVM Tainted: G W RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0 Code: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be RSP: 0018:ffffaa90087679b0 EFLAGS: 00010046 RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffe3f37905b900 ... CR2: 0000000000000068 CR3: 00000004c5898003 CR4: 00000000001726e0 Call Trace: get_user_pages_fast_only+0x13/0x20 hva_to_pfn+0xa9/0x3e0 try_async_pf+0xa1/0x270 direct_page_fault+0x113/0xad0 kvm_mmu_page_fault+0x69/0x680 vmx_handle_exit+0xe1/0x5d0 kvm_arch_vcpu_ioctl_run+0xd81/0x1c70 kvm_vcpu_ioctl+0x267/0x670 __x64_sys_ioctl+0x83/0xa0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/secretmem: corrige la página NULL->desreferencia de mapeo en page_is_secretmem() Verifique si hay una página NULL->mapping antes de desreferenciar el mapeo en page_is_secretmem(), ya que el mapeo de la página puede ser anulado mientras se ejecuta gup(), por ejemplo, mediante recuperación o truncamiento. ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000068 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 4173897 Comunicaciones: CPU 3/KVM contaminada: GW RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0 Código: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be RSP: ffffaa90087679 b0 EFLAGS: 00010046 RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934 RDX: 0000000000000000 RSI: 00000000000000000 RDI: ffffe3f37905b900 ... CR2: 0000068 CR3: 00000004c5898003 CR4: 00000000001726e0 Seguimiento de llamadas: get_user_pages_fast_only+0x13/0x20 hva_to_pfn+0xa9/0x3e0 try_async_pf+0xa1/0x270 direct_page_fault+0x113/ 0xad0 kvm_mmu_page_fault+0x69/0x680 vmx_handle_exit+0xe1/0x5d0 kvm_arch_vcpu_ioctl_run+0xd81/0x1c70 kvm_vcpu_ioctl+0x267/0x670 __x64_sys_ioctl+0x83/0xa0 scall_64+0x56/0x80 entrada_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 https://git.kernel.org/stable/c/b77ba1e02345bafd703f0d407bdbd88c3be1f767 https://git.kernel.org/stable/c/79f9bc5843142b649575f887dccdf1c07ad75c20 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47462 – mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()
https://notcve.org/view.php?id=CVE-2021-47462
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() syzbot reported access to unitialized memory in mbind() [1] Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes") This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in do_set_mempolicy() This patch moves the check in sanitize_mpol_flags() so that it is also used by mbind() [1] BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_alloc_node mm/slub.c:3221 [inline] slab_alloc mm/slub.c:3230 [inline] kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235 mpol_new mm/mempolicy.c:293 [inline] do_mbind+0x912/0x15f0 mm/mempolicy.c:1289 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae ===================================================== Kernel panic - not syncing: panic_on_kmsan set ... CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G B 5.15.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106 dump_stack+0x25/0x28 lib/dump_stack.c:113 panic+0x44f/0xdeb kernel/panic.c:232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: no permitir MPOL_F_NUMA_BALANCING ilegal | MPOL_LOCAL en mbind() syzbot informó acceso a la memoria unificada en mbind() [1] El problema surgió con el commit bda420b98505 ("equilibrio numa: migrar en caso de falla entre múltiples nodos vinculados") Esta confirmación agregó un nuevo bit en MPOL_MODE_FLAGS, pero solo marcó que era válido combinación (MPOL_F_NUMA_BALANCING solo se puede usar con MPOL_BIND) en do_set_mempolicy() Este parche mueve la verificación en sanitize_mpol_flags() para que también sea usado por mbind() [1] ERROR: KMSAN: valor uninit en __mpol_equal+0x567/0x590 mm /mempolicy.c:2260 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [en línea] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/ mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [en línea] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c: 1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0 Unidad x44/0xae fue creado en: slab_alloc_node mm/slub.c:3221 [en línea] slab_alloc mm/slub.c:3230 [en línea] kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235 mpol_new mm/mempolicy.c:293 [en línea] do_mbind +0x912/0x15f0 mm/mempolicy.c:1289 kernel_mbind mm/mempolicy.c:1483 [en línea] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0 x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae ======= =============================================== Pánico del kernel - no sincronización: pánico_on_kmsan set... CPU: 0 PID: 15049 Comm: syz-executor.0 Contaminado: GB 5.15.0-rc2-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/ Seguimiento de llamadas de 2011: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106 dump_stack+0x25/0x28 lib/dump_stack.c:113 pánico+0x44f/0xdeb kernel/panic.c: 232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h: 105 [en línea] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [en línea ] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common. c:51 [en línea ] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/bda420b985054a3badafef23807c4b4fa38a3dff https://git.kernel.org/stable/c/9ee4e9ae98f1f262d6fae0d266cfdf3ba2c321d9 https://git.kernel.org/stable/c/6d2aec9e123bb9c49cb5c7fc654f25f81e688e8c •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47461 – userfaultfd: fix a race between writeprotect and exit_mmap()
https://notcve.org/view.php?id=CVE-2021-47461
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a race between writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap() and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race as done in other userfaultfd operations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: userfaultfd: corrige una ejecución entre writeprotect y exit_mmap() Una ejecución es posible cuando un proceso sale, sus VMA son eliminados por exit_mmap() y al mismo tiempo se llama a userfaultfd_writeprotect() . KASAN detectó la ejecución en un núcleo de desarrollo, pero parece ser posible también en núcleos de vainilla. Utilice mmget_not_zero() para evitar la ejecución como se hace en otras operaciones de userfaultfd. • https://git.kernel.org/stable/c/63b2d4174c4ad1f40b48d7138e71bcb564c1fe03 https://git.kernel.org/stable/c/3cda4bfffd4f755645577aaa9e96a606657b4525 https://git.kernel.org/stable/c/149958ecd0627a9f1e9c678c25c665400054cd6a https://git.kernel.org/stable/c/cb185d5f1ebf900f4ae3bf84cee212e6dd035aca https://access.redhat.com/security/cve/CVE-2021-47461 https://bugzilla.redhat.com/show_bug.cgi?id=2282896 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •