CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46931 – net/mlx5e: Wrap the tx reporter dump callback to extract the sq
https://notcve.org/view.php?id=CVE-2021-46931
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Wrap the tx reporter dump callback to extract the sq Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? • https://git.kernel.org/stable/c/5f29458b77d51c104554575b73184c243930aa87 https://git.kernel.org/stable/c/73665165b64a8f3c5b3534009a69be55bb744f05 https://git.kernel.org/stable/c/07f13d58a8ecc3baf9a488588fb38c5cb0db484f https://git.kernel.org/stable/c/918fc3855a6507a200e9cf22c20be852c0982687 • CWE-787: Out-of-bounds Write •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46930 – usb: mtu3: fix list_head check warning
https://notcve.org/view.php?id=CVE-2021-46930
In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: fix list_head check warning This is caused by uninitialization of list_head. BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4 Call trace: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: mtu3: corrección de advertencia de verificación de list_head Esto se debe a la desinicialización de list_head. ERROR: KASAN: uso después de la liberación en __list_del_entry_valid+0x34/0xe4 Rastreo de llamadas: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report +0x14/0x20 __asan_load8+ 0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4 • https://git.kernel.org/stable/c/83374e035b6286731c5aa617844c7b724294c2a7 https://git.kernel.org/stable/c/585e2b244dda7ea733274e4b8fa27853d625d3bf https://git.kernel.org/stable/c/3b6efe0b7ba03cc2acf0694b46d6ff33c5b4c295 https://git.kernel.org/stable/c/249ddfbe00570d6dc76208e88017937d4d374c79 https://git.kernel.org/stable/c/8c313e3bfd9adae8d5c4ba1cc696dcbc86fbf9bf • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46929 – sctp: use call_rcu to free endpoint
https://notcve.org/view.php?id=CVE-2021-46929
In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk). To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff will happen either until release_sock. Note that delaying endpoint free won't delay the port release, as the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv(). Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sctp: use call_rcu para liberar el endpoint. Este parche tiene como objetivo retrasar la liberación del endpoint llamando a call_rcu() para solucionar otro problema de use-after-free en sctp_sock_dump(): ERROR: KASAN: use-after-free en __lock_acquire+0x36d9/0x4c20 Rastreo de llamadas: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h :135 [en línea] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [en línea] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/ 0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [en línea] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c: 5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x6 06/0x1080 neto/ netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [en línea] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cm re neto /core/sock_diag.c:232 [en línea] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag. c:274 Este problema ocurre cuando se quita asoc y se libera el sk antiguo después de obtenerlo mediante asoc->base.sk y antes de llamar a lock_sock(sk). Para evitar que sk se libere, como titular de sk, ep debe estar activo al llamar a lock_sock(). • https://git.kernel.org/stable/c/d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab https://git.kernel.org/stable/c/8873140f95d4977bf37e4cf0d5c5e3f6e34cdd3e https://git.kernel.org/stable/c/af6e6e58f7ebf86b4e7201694b1e4f3a62cbc3ec https://git.kernel.org/stable/c/831de271452b87657fcf8d715ee20519b79caef5 https://git.kernel.org/stable/c/769d14abd35e0e153b5149c3e1e989a9d719e3ff https://git.kernel.org/stable/c/75799e71df1da11394740b43ae5686646179561d https://git.kernel.org/stable/c/5ec7d18d1813a5bead0b495045606c93873aecbb • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46928 – parisc: Clear stale IIR value on instruction access rights trap
https://notcve.org/view.php?id=CVE-2021-46928
In the Linux kernel, the following vulnerability has been resolved: parisc: Clear stale IIR value on instruction access rights trap When a trap 7 (Instruction access rights) occurs, this means the CPU couldn't execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didn't even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19. This patch simply overwrites the stale IIR value with a constant magic "bad food" value (0xbaadf00d), in the hope people don't start to try to understand the various random IIR values in trap 7 dumps. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: parisc: borra el valor IIR obsoleto en la trampa de derechos de acceso a instrucciones Cuando ocurre una trampa 7 (derechos de acceso a instrucciones), esto significa que la CPU no pudo ejecutar una instrucción debido a que faltan permisos de ejecución en la región de la memoria. En este caso, parece que la CPU ni siquiera obtuvo la instrucción de la memoria y, por lo tanto, no la almacenó en el registro cr19 (IIR) antes de llamar al controlador de trampas. • https://git.kernel.org/stable/c/d01e9ce1af6116f812491d3d3873d204f10ae0b8 https://git.kernel.org/stable/c/e96373f0a5f484bc1e193f9951dcb3adf24bf3f7 https://git.kernel.org/stable/c/484730e5862f6b872dca13840bed40fd7c60fa26 • CWE-755: Improper Handling of Exceptional Conditions •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46927 – nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert
https://notcve.org/view.php?id=CVE-2021-46927
In the Linux kernel, the following vulnerability has been resolved: nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert After commit 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()"), the call to get_user_pages() will trigger the mmap assert. static inline void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock); VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [ 62.521410] kernel BUG at include/linux/mmap_lock.h:156! ........................................................... [ 62.538938] RIP: 0010:find_vma+0x32/0x80 ........................................................... [ 62.605889] Call Trace: [ 62.608502] <TASK> [ 62.610956] ? lock_timer_base+0x61/0x80 [ 62.614106] find_extend_vma+0x19/0x80 [ 62.617195] __get_user_pages+0x9b/0x6a0 [ 62.620356] __gup_longterm_locked+0x42d/0x450 [ 62.623721] ? finish_wait+0x41/0x80 [ 62.626748] ? • https://git.kernel.org/stable/c/5b78ed24e8ec48602c1d6f5a188e58d000c81e2b https://git.kernel.org/stable/c/90d2beed5e753805c5eab656b8d48257638fe543 https://git.kernel.org/stable/c/3a0152b219523227c2a62a0a122cf99608287176 • CWE-667: Improper Locking •