CVSS: 4.7EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47393 – hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
https://notcve.org/view.php?id=CVE-2021-47393
In the Linux kernel, the following vulnerability has been resolved: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature. Request for changing fan minimum speed is configuration request and can be set only through 'sysfs' write procedure. In this situation value of argument 'state' is above nominal fan speed maximum. Return non-zero code in this case to avoid thermal_cooling_device_stats_update() call, because in this case statistics update violates thermal statistics table range. The issues is observed in case kernel is configured with option CONFIG_THERMAL_STATISTICS. Here is the trace from KASAN: [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444 [ 159.545625] Call Trace: [ 159.548366] dump_stack+0x92/0xc1 [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] thermal_zone_device_update+0x345/0x780 [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core] [ 159.700972] ? • https://git.kernel.org/stable/c/65afb4c8e7e4e7e74b28efa1df62da503ca3e7a6 https://git.kernel.org/stable/c/5c6e0bce647d9cb32a17d58ffa669b3421fcc6ca https://git.kernel.org/stable/c/a6c42ae1530f94724d3c42cf91fe3d3c5e394f8a https://git.kernel.org/stable/c/76bbb482d33bfcd7e9070ecf594c9ec73e01c930 https://git.kernel.org/stable/c/aa85fb7bde558bb2e364e85976b14b259c8b6fe8 https://git.kernel.org/stable/c/e6fab7af6ba1bc77c78713a83876f60ca7a4a064 https://access.redhat.com/security/cve/CVE-2021-47393 https://bugzilla.redhat.com/show_bug.cgi?id=2282345 • CWE-754: Improper Check for Unusual or Exceptional Conditions •
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: -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 •