CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47391 – RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
https://notcve.org/view.php?id=CVE-2021-47391
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests The FSM can run in a circle allowing rdma_resolve_ip() to be called twice on the same id_priv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): for #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. handler still running ..] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the req_list rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // process_one_req() self removes it spin_lock_bh(&lock); cancel_delayed_work(&req->work); if (!list_empty(&req->list)) == true ! rdma_addr_cancel() returns after process_on_req #1 is done kfree(id_priv) process_one_req(): for #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! • https://git.kernel.org/stable/c/e51060f08a61965c4dd91516d82fe90617152590 https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589 https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47390 – KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()
https://notcve.org/view.php?id=CVE-2021-47390
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() KASAN reports the following issue: BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? • https://git.kernel.org/stable/c/7ee30bc132c683d06a6d9e360e39e483e3990708 https://git.kernel.org/stable/c/bebabb76ad9acca8858e0371e102fb60d708e25b https://git.kernel.org/stable/c/99a9e9b80f19fc63be005a33d76211dd23114792 https://git.kernel.org/stable/c/2f9b68f57c6278c322793a06063181deded0ad69 •
CVSS: 5.1EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47389 – KVM: SVM: fix missing sev_decommission in sev_receive_start
https://notcve.org/view.php?id=CVE-2021-47389
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: fix missing sev_decommission in sev_receive_start DECOMMISSION the current SEV context if binding an ASID fails after RECEIVE_START. Per AMD's SEV API, RECEIVE_START generates a new guest context and thus needs to be paired with DECOMMISSION: The RECEIVE_START command is the only command other than the LAUNCH_START command that generates a new guest context and guest handle. The missing DECOMMISSION can result in subsequent SEV launch failures, as the firmware leaks memory and might not able to allocate more SEV guest contexts in the future. Note, LAUNCH_START suffered the same bug, but was previously fixed by commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID binding fails"). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: corrige la falta de sev_decommission en sev_receive_start DESCOMMISSION el contexto SEV actual si falla la vinculación de un ASID después de RECEIVE_START. Según la API SEV de AMD, RECEIVE_START genera un nuevo contexto de invitado y, por lo tanto, debe combinarse con DECOMMISSION: el comando RECEIVE_START es el único comando, además del comando LAUNCH_START, que genera un nuevo contexto de invitado y un identificador de invitado. La DESCOMISIÓN faltante puede provocar fallas de inicio de SEV posteriores, ya que el firmware pierde memoria y es posible que no pueda asignar más contextos de invitados de SEV en el futuro. • https://git.kernel.org/stable/c/af43cbbf954b50ca97d5e7bb56c2edc6ffd209ef https://git.kernel.org/stable/c/efd7866e114dcb44f86d151e843f8276b7efbc67 https://git.kernel.org/stable/c/f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 • CWE-772: Missing Release of Resource after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47388 – mac80211: fix use-after-free in CCMP/GCMP RX
https://notcve.org/view.php?id=CVE-2021-47388
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix use-after-free in CCMP/GCMP RX When PN checking is done in mac80211, for fragmentation we need to copy the PN to the RX struct so we can later use it to do a comparison, since commit bf30ca922a0c ("mac80211: check defrag PN against current frame"). Unfortunately, in that commit I used the 'hdr' variable without it being necessarily valid, so use-after-free could occur if it was necessary to reallocate (parts of) the frame. Fix this by reloading the variable after the code that results in the reallocations, if any. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: corrige el use after free en CCMP/GCMP RX. Cuando se realiza la verificación de PN en mac80211, para la fragmentación necesitamos copiar el PN a la estructura RX para poder usarlo más tarde. para hacer una comparación, desde la confirmación bf30ca922a0c ("mac80211: verifique la desfragmentación PN con el marco actual"). Desafortunadamente, en esa confirmación utilicé la variable 'hdr' sin que fuera necesariamente válida, por lo que podría ocurrir un use after free si fuera necesario reasignar (partes de) el marco. • https://git.kernel.org/stable/c/608b0a2ae928a74a2f89e02227339dd79cdb63cf https://git.kernel.org/stable/c/d0f613fe6de344dc17ba04a88921a2094c13d3fa https://git.kernel.org/stable/c/a9b57952fed41556c950a92123086724eaf11919 https://git.kernel.org/stable/c/0f716b48ed25503e6961f4b5b40ece36f7e4ed26 https://git.kernel.org/stable/c/c8b3a6150dc8ac78d5fdd5fbdfc4806249ef8b2c https://git.kernel.org/stable/c/e64ea0597050157f926ac2ba9b478a44ee5be945 https://git.kernel.org/stable/c/bf30ca922a0c0176007e074b0acc77ed345e9990 https://git.kernel.org/stable/c/1f0bf30c01d3f4de7d6c5e27b102a808c •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47387 – cpufreq: schedutil: Use kobject release() method to free sugov_tunables
https://notcve.org/view.php?id=CVE-2021-47387
In the Linux kernel, the following vulnerability has been resolved: cpufreq: schedutil: Use kobject release() method to free sugov_tunables The struct sugov_tunables is protected by the kobject, so we can't free it directly. Otherwise we would get a call trace like this: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30 WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001ecaf910 x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80 x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20 x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365 x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0 x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001 x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000 x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1c0/0x230 debug_check_no_obj_freed+0x20/0x88 slab_free_freelist_hook+0x154/0x1c8 kfree+0x114/0x5d0 sugov_exit+0xbc/0xc0 cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x268/0x4a8 store_scaling_governor+0xe0/0x128 store+0xc0/0xf0 sysfs_kf_write+0x54/0x80 kernfs_fop_write_iter+0x128/0x1c0 new_sync_write+0xf0/0x190 vfs_write+0x2d4/0x478 ksys_write+0x74/0x100 __arm64_sys_write+0x24/0x30 invoke_syscall.constprop.0+0x54/0xe0 do_el0_svc+0x64/0x158 el0_svc+0x2c/0xb0 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x198/0x19c irq event stamp: 5518 hardirqs last enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8 hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0 softirqs last enabled at (5504): [<ffff8000100106e0>] __do_softirq+0x4d0/0x6c0 softirqs last disabled at (5483): [<ffff800010049548>] irq_exit+0x1b0/0x1b8 So split the original sugov_tunables_free() into two functions, sugov_clear_global_tunables() is just used to clear the global_tunables and the new sugov_tunables_free() is used as kobj_type::release to release the sugov_tunables safely. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: schedutil: utilice el método kobject release() para liberar sugov_tunables. La estructura sugov_tunables está protegida por kobject, por lo que no podemos liberarla directamente. De lo contrario, obtendríamos un seguimiento de llamada como este: ODEBUG: activo libre (estado activo 0) tipo de objeto: timer_list sugerencia: delay_work_timer_fn+0x0/0x30 ADVERTENCIA: CPU: 3 PID: 720 en lib/debugobjects.c:505 debug_print_object+0xb8/ 0x100 Módulos vinculados en: CPU: 3 PID: 720 Comm: a.sh Contaminado: GW 5.14.0-rc1-next-20210715-yocto-standard+ #507 Nombre del hardware: Placa Marvell OcteonTX CN96XX (DT) pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc: debug_print_object+0xb8/0x100 lr: debug_print_object+0xb8/0x100 sp: ffff80001ecaf910 x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: d80 x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 x23: ffff80001142aa68 x22 : ffff800011043d80 x21: ffff00010de46f20 x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 x17: 6e6968207473696c x16: 656d6974203a x15: 6570797420746365 x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 x11: ffff8000124b1560 x10: 0012331520 x9: ffff8000100ca6b0 x8: 000000000017ffe8 x7: c0000000fffeffff x6: 0000000000000001 x5: ffff800011d8c000 x4: ffff800011d8c740 x3: 0000000000000000 x2: ffff0001108301c0 x1: ab3c90eedf9c0f00 x0: 0000000000000000 Rastreo de llamadas: xb8/0x100 __debug_check_no_obj_freed+0x1c0/0x230 debug_check_no_obj_freed+0x20/0x88 slab_free_freelist_hook+0x154/0x1c8 kfree+0x114/0x5d0 sugov_exit+0xbc/ 0xc0 cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x268/0x4a8 store_scaling_governor+0xe0/0x128 store+0xc0/0xf0 sysfs_kf_write+0x54/0x80 kernfs_fop_write_iter+0x128/0x1c0 nuevo _sync_write+0xf0/0x190 vfs_write+0x2d4/0x478 ksys_write+0x74/0x100 __arm64_sys_write+0x24/ 0x30 invoke_syscall.constprop.0+0x54/0xe0 do_el0_svc+0x64/0x158 el0_svc+0x2c/0xb0 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x198/0x19c sello de evento irq: 5518 hardirqs habilitado por última vez en ( 5517): [] consola_unlock+ 0x554/0x6c8 hardirqs deshabilitado por última vez en (5518): [] el1_dbg+0x28/0xa0 softirqs habilitado por última vez en (5504): [] __do_softirq+0x4d0/0x6c0 softirqs deshabilitado por última vez en (5483): ff800010049548 >] irq_exit+0x1b0/0x1b8 Entonces divida el sugov_tunables_free() original en dos funciones, sugov_clear_global_tunables() solo se usa para borrar los global_tunables y el nuevo sugov_tunables_free() se usa como kobj_type::release para liberar los sugov_tunables de forma segura. • https://git.kernel.org/stable/c/9bdcb44e391da5c41b98573bf0305a0e0b1c9569 https://git.kernel.org/stable/c/cb4a53ba37532c861a5f3f22803391018a41849a https://git.kernel.org/stable/c/463c46705f321201090b69c4ad5da0cd2ce614c9 https://git.kernel.org/stable/c/30d57cf2c4116ca6d34ecd1cac94ad84f8bc446c https://git.kernel.org/stable/c/67c98e023135ff81b8d52998a6fdb8ca0c518d82 https://git.kernel.org/stable/c/a7d4fc84404d45d72f4490417e8cc3efa4af93f1 https://git.kernel.org/stable/c/8d62aec52a8c5b1d25a2364b243fcc5098a2ede9 https://git.kernel.org/stable/c/e5c6b312ce3cc97e90ea159446e6bfa06 •