CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47392 – RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure
https://notcve.org/view.php?id=CVE-2021-47392
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure If cma_listen_on_all() fails it leaves the per-device ID still on the listen_list but the state is not set to RDMA_CM_ADDR_BOUND. When the cmid is eventually destroyed cma_cancel_listens() is not called due to the wrong state, however the per-device IDs are still holding the refcount preventing the ID from being destroyed, thus deadlocking: task:rping state:D stack: 0 pid:19605 ppid: 47036 flags:0x00000084 Call Trace: __schedule+0x29a/0x780 ? free_unref_page_commit+0x9b/0x110 schedule+0x3c/0xa0 schedule_timeout+0x215/0x2b0 ? __flush_work+0x19e/0x1e0 wait_for_completion+0x8d/0xf0 _destroy_id+0x144/0x210 [rdma_cm] ucma_close_id+0x2b/0x40 [rdma_ucm] __destroy_id+0x93/0x2c0 [rdma_ucm] ? __xa_erase+0x4a/0xa0 ucma_destroy_id+0x9a/0x120 [rdma_ucm] ucma_write+0xb8/0x130 [rdma_ucm] vfs_write+0xb4/0x250 ksys_write+0xb5/0xd0 ? syscall_trace_enter.isra.19+0x123/0x190 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Ensure that cma_listen_on_all() atomically unwinds its action under the lock during error. • https://git.kernel.org/stable/c/70ba8b1697e35c04ea5f22edb6e401aeb1208d96 https://git.kernel.org/stable/c/c80a0c52d85c49a910d0dc0e342e8d8898677dc0 https://git.kernel.org/stable/c/3f4e68902d2e545033c80d7ad62fd9a439e573f4 https://git.kernel.org/stable/c/e56a5146ef8cb51cd7c9e748267dce7564448a35 https://git.kernel.org/stable/c/ca465e1f1f9b38fe916a36f7d80c5d25f2337c81 •
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 •