CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47395 – mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
https://notcve.org/view.php?id=CVE-2021-47395
In the Linux kernel, the following vulnerability has been resolved: mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap routine in order to fix the following warning reported by syzbot: WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modules linked in: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [inline] __bpf_redirect_no_mac net/core/filter.c:2139 [inline] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline] __bpf_prog_run include/linux/filter.h:624 [inline] bpf_prog_run include/linux/filter.h:631 [inline] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline] __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: límite inyectado de vht mcs/nss en ieee80211_parse_tx_radiotap. Limite los valores máximos para vht mcs y nss en la rutina ieee80211_parse_tx_radiotap para corregir la siguiente advertencia reportada por syzbot: ADVERTENCIA: CPU: 0 PID : 10717 en include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] ADVERTENCIA: CPU: 0 PID: 10717 en include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12 d0 neto/ mac80211/tx.c:2244 Módulos vinculados en: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01 /2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 86f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000ffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 000000000015 06f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000600 ieee80211_monitor_select_queue+0xa6 /0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [ en línea] __bpf_redirect_no_mac net/core/filter.c:2139 [en línea] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [en línea] bpf_clone_redirect+0x2ae/0x420 net/core /filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [en línea] __bpf_prog_run include/linux/filter.h:624 [en línea] bpf_prog_run include/linux/filter.h:631 [ en línea] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [en línea] 5df0 núcleo/bpf/ syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4689 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 4 arco/x86/ entrada/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 • https://git.kernel.org/stable/c/646e76bb5daf4ca38438c69ffb72cccb605f3466 https://git.kernel.org/stable/c/e5bb852aa2ad963074f0ad73030dbc20a30853e3 https://git.kernel.org/stable/c/ce5f372f5f084ff51c285fc27b232f15a3d00f0b https://git.kernel.org/stable/c/76538c7b4df314bb937e44c5cb1782f37d47443c https://git.kernel.org/stable/c/ab85997465b972d39d9747fc16311fa5773374b2 https://git.kernel.org/stable/c/1282bb00835ff79d2d9c023055d514df5b4de260 https://git.kernel.org/stable/c/997ee230e4f5285cd98445c102d9033c7ec4814b https://git.kernel.org/stable/c/13cb6d826e0ac0d144b0d48191ff1a111 •
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 •