Page 131 of 5250 results (0.007 seconds)

CVSS: 5.6EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hns3: corrige el error de use-after-free en hclgevf_send_mbx_msg Actualmente, la función hns3_remove desinstala primero la instancia del cliente y luego desinstala el dispositivo del motor de aceleración. El dispositivo de red se libera en el proceso de desinstalación de la instancia del cliente, pero el proceso de desinstalación del dispositivo del motor de aceleración aún lo utiliza para rastrear la información del tiempo de ejecución. • https://git.kernel.org/stable/c/d8355240cf8fb8b9e002b5c8458578435cea85c2 https://git.kernel.org/stable/c/12512bc8f25b8ba9795dfbae0e9ca57ff13fd542 https://git.kernel.org/stable/c/4f4a353f6fe033807cd026a5de81c67469ff19b0 https://git.kernel.org/stable/c/27cbf64a766e86f068ce6214f04c00ceb4db1af4 https://access.redhat.com/security/cve/CVE-2021-47596 https://bugzilla.redhat.com/show_bug.cgi?id=2293230 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mptcp: clear 'kern' flag from fallback sockets The mptcp ULP extension relies on sk->sk_sock_kern being set correctly: It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); from working for plain tcp sockets (any userspace-exposed socket). But in case of fallback, accept() can return a plain tcp sk. In such case, sk is still tagged as 'kernel' and setsockopt will work. This will crash the kernel, The subflow extension has a NULL ctx->conn mptcp socket: BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0 Call Trace: tcp_data_ready+0xf8/0x370 [..] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: borrar el indicador 'kern' de los sockets de reserva La extensión mptcp ULP depende de que sk->sk_sock_kern esté configurado correctamente: impide que setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); de funcionar para sockets tcp simples (cualquier socket expuesto al espacio de usuario). Pero en caso de respaldo, aceptar() puede devolver un sk tcp simple. En tal caso, sk todavía está etiquetado como 'kernel' y setsockopt funcionará. Esto bloqueará el kernel. • https://git.kernel.org/stable/c/cf7da0d66cc1a2a19fc5930bb746ffbb2d4cd1be https://git.kernel.org/stable/c/451f1eded7f56e93aaf52eb547ba97742d9c0e97 https://git.kernel.org/stable/c/c26ac0ea3a91c210cf90452e625dc441adf3e549 https://git.kernel.org/stable/c/d6692b3b97bdc165d150f4c1505751a323a80717 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: igbvf: fix double free in `igbvf_probe` In `igbvf_probe`, if register_netdev() fails, the program will go to label err_hw_init, and then to label err_ioremap. In free_netdev() which is just below label err_ioremap, there is `list_for_each_entry_safe` and `netif_napi_del` which aims to delete all entries in `dev->napi_list`. The program has added an entry `adapter->rx_ring->napi` which is added by `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has been freed below label err_hw_init. So this a UAF. In terms of how to patch the problem, we can refer to igbvf_remove() and delete the entry before `adapter->rx_ring`. The KASAN logs are as follows: [ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450 [ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366 [ 35.128360] [ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 35.131749] Call Trace: [ 35.132199] dump_stack_lvl+0x59/0x7b [ 35.132865] print_address_description+0x7c/0x3b0 [ 35.133707] ? free_netdev+0x1fd/0x450 [ 35.134378] __kasan_report+0x160/0x1c0 [ 35.135063] ? • https://git.kernel.org/stable/c/d4e0fe01a38a073568aee541a0247fe734095979 https://git.kernel.org/stable/c/ffe1695b678729edec04037e691007900a2b2beb https://git.kernel.org/stable/c/79d9b092035dcdbe636b70433149df9cc6db1e49 https://git.kernel.org/stable/c/8d0c927a9fb2b4065230936b77b54f857a3754fc https://git.kernel.org/stable/c/cc9b655bb84f1be283293dfea94dff9a31b106ac https://git.kernel.org/stable/c/8addba6cab94ce01686ea2e80ed1530f9dc33a9a https://git.kernel.org/stable/c/74a16e062b23332d8db017ff4a41e16279c44411 https://git.kernel.org/stable/c/944b8be08131f5faf2cd2440aa1c24a39 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: sit: do not call ipip6_dev_free() from sit_init_net() ipip6_dev_free is sit dev->priv_destructor, already called by register_netdevice() if something goes wrong. Alternative would be to make ipip6_dev_free() robust against multiple invocations, but other drivers do not implement this strategy. syzbot reported: dst_release underflow WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Modules linked in: CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173 Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sit: no llame a ipip6_dev_free() desde sit_init_net() ipip6_dev_free es sit dev-&gt;priv_destructor, ya llamado por Register_netdevice() si algo sale mal. La alternativa sería hacer que ipip6_dev_free() sea robusto contra múltiples invocaciones, pero otros controladores no implementan esta estrategia. syzbot informó: dst_release underflow ADVERTENCIA: CPU: 0 PID: 5059 en net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Módulos vinculados en: CPU: 1 PID: 5059 Comm: syz -executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c :173 Código: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 &lt;0f&gt; 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08 : ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb135 8 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ ipv6/sit.c:1414 [en línea] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c :326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 .c :3075 __do_sys_unshare kernel/fork.c:3146 [en línea] __se_sys_unshare kernel/fork.c:3144 [en línea] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [en línea ] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP:00 007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000 000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000 00246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000 • https://git.kernel.org/stable/c/cf124db566e6b036b8bcbe8decbed740bdfac8c6 https://git.kernel.org/stable/c/95876855a55072572895a236b156ffb357fd5538 https://git.kernel.org/stable/c/4e1797914d8f223726ff6ae5ece4f97d73f21bab https://git.kernel.org/stable/c/e56b65c1e74d7f706d74b51baba15187be2fb4b5 https://git.kernel.org/stable/c/ad0ed314d6167b212939e3839428ba0c8bb16adb https://git.kernel.org/stable/c/6f46c59e60b64620d5d386c8ee2eaa11ebe3b595 https://git.kernel.org/stable/c/44a6c846bc3a7efe7d394bab8b2ae3b7f580e190 https://git.kernel.org/stable/c/e28587cc491ef0f3c51258fdc87fbc386 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: systemport: Add global locking for descriptor lifecycle The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues. This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length. The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer. The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITE_PORT_{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: systemport: agregue bloqueo global para el ciclo de vida del descriptor. La lista de descriptores es un recurso compartido entre todas las colas de transmisión y el mecanismo de bloqueo que se usa hoy solo protege la concurrencia en una cola de transmisión determinada. entre la transmisión y la recuperación. • https://git.kernel.org/stable/c/80105befdb4b8cea924711b40b2462b87df65b62 https://git.kernel.org/stable/c/8ed2f5d08d6e59f8c78b2869bfb95d0be32c094c https://git.kernel.org/stable/c/de57f62f76450b934de8203711bdc4f7953c3421 https://git.kernel.org/stable/c/f3fde37d3f0d429f0fcce214cb52588a9e21260e https://git.kernel.org/stable/c/595a684fa6f23b21958379a18cfa83862c73c2e1 https://git.kernel.org/stable/c/c675256a7f131f5ba3f331efb715e8f31ea0e392 https://git.kernel.org/stable/c/6e1011cd183faae8daff275c72444edcdfe0d473 https://git.kernel.org/stable/c/eb4687c7442942e115420a30185f8d83f •