CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47394 – netfilter: nf_tables: unlink table before deleting it
https://notcve.org/view.php?id=CVE-2021-47394
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unlink table before deleting it syzbot reports following UAF: BUG: KASAN: use-after-free in memcmp+0x18f/0x1c0 lib/string.c:955 nla_strcmp+0xf2/0x130 lib/nlattr.c:836 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [inline] nf_tables_getset+0x1b3/0x860 net/netfilter/nf_tables_api.c:4064 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 Problem is that all get operations are lockless, so the commit_mutex held by nft_rcv_nl_event() isn't enough to stop a parallel GET request from doing read-accesses to the table object even after synchronize_rcu(). To avoid this, unlink the table first and store the table objects in on-stack scratch space. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: desvincular la tabla antes de eliminarla syzbot informa de lo sigueinte. UAF: BUG: KASAN: use-after-free en memcmp+0x18f/0x1c0 lib/string.c:955 nla_strcmp+ 0xf2/0x130 lib/nlattr.c:836 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [en línea] nf_tables_getset+0x1b3/0x860 net /filtro de red/ nf_tables_api.c:4064 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 El problema es que todas las operaciones de obtención no tienen bloqueo, por lo que el commit_mutex mantenido por () no es suficiente para evitar que una solicitud GET paralela realice accesos de lectura al objeto de la tabla incluso después de sincronizar_rcu(). Para evitar esto, primero desvincule la tabla y almacene los objetos de la tabla en el espacio temporal de la pila. • https://git.kernel.org/stable/c/6001a930ce0378b62210d4f83583fc88a903d89d https://git.kernel.org/stable/c/f65c73d3aabb87d4353e0bc4a718b5ae8c43fd04 https://git.kernel.org/stable/c/a499b03bf36b0c2e3b958a381d828678ab0ffc5e •
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 •