CVSS: 7.3EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47596 – net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg
https://notcve.org/view.php?id=CVE-2021-47596
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: 2EXPL: 0CVE-2021-47595 – net/sched: sch_ets: don't remove idle classes from the round-robin list
https://notcve.org/view.php?id=CVE-2021-47595
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_ets: don't remove idle classes from the round-robin list Shuang reported that the following script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 crashes systematically when line 2) is commented: list_del corruption, ffff8e028404bd30->next is LIST_POISON1 (dead000000000100) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:47! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0 Call Trace: <TASK> ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7efdc8031338 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets] ---[ end trace f35878d1912655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: sch_ets: no elimine las clases inactivas de la lista de turnos Shuang informó que el siguiente script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bandas 8 estricto 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a propio -b 00:c1:a0: c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 estricto 2 cuantos 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 falla sistemáticamente cuando la línea 2) se comenta: corrupción list_del, ffff8e028404bd30->el siguiente es LIST_POISON1 (dead000000000100) ------------[ cortar aquí ]------------ ERROR del kernel en lib/list_debug. c:47! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comunicaciones: tc Not tainted 5.16.0-rc4+ #478 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066 +0f1aadab 01/04/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 4 8 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 246 RAX: 000000000000004eRBX : 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 00000000000 00000 R09: c0000000ffff7fff R10: 00000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 000000000035 0ef0 Seguimiento de llamadas: ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/ 0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7efdc8031338 Código: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: de RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 00000000000000246 R12: 0000000000000001 R 13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 Módulos vinculados en: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common pcs pkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [última descarga: sch_ets] ---[ fin de seguimiento f35878d191 2655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX 000 0000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: FFFFFAE46807A36A8 R12: FFFFF8E028404B800 R13: FFFF8E028404BD30 R14: Dead000000000100 R15: FFFFF8E02FAFA2400 FUT: GS: FFFF8E02FB600000 (0000) KNLGS: 000000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 - --truncado--- • https://git.kernel.org/stable/c/ae2659d2c670252759ee9c823c4e039c0e05a6f2 https://git.kernel.org/stable/c/e25bdbc7e951ae5728fee1f4c09485df113d013c https://git.kernel.org/stable/c/81fbdd45652d8605a029e78ef14a6aaa529c4e72 https://git.kernel.org/stable/c/491c1253441e2fdc8f6a6f4976e3f13440419b7a https://git.kernel.org/stable/c/c062f2a0b04d86c5b8c9d973bea43493eaca3d32 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47594 – mptcp: never allow the PM to close a listener subflow
https://notcve.org/view.php?id=CVE-2021-47594
In the Linux kernel, the following vulnerability has been resolved: mptcp: never allow the PM to close a listener subflow Currently, when deleting an endpoint the netlink PM treverses all the local MPTCP sockets, regardless of their status. If an MPTCP listener socket is bound to the IP matching the delete endpoint, the listener TCP socket will be closed. That is unexpected, the PM should only affect data subflows. Additionally, syzbot was able to trigger a NULL ptr dereference due to the above: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897 Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016 RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000 R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0 Call Trace: <TASK> lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket.c:1864 [inline] __se_sys_accept net/socket.c:1861 [inline] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 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:0x7f177cd8b8e9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c R13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000 </TASK> Fix the issue explicitly skipping MPTCP socket in TCP_LISTEN status. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: nunca permitir que el PM cierre un subflujo de escucha Actualmente, al eliminar un endpoint, el PM de netlink atraviesa todos los sockets MPTCP locales, independientemente de su estado. Si un socket de escucha MPTCP está vinculado a la IP que coincide con el endpoint de eliminación, el socket TCP de escucha se cerrará. Esto es inesperado, el PM solo debería afectar los subflujos de datos. Además, syzbot pudo activar una desreferencia de ptr NULL debido a lo anterior: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000018-0x0000000000000001f] CPU: 1 PID: 6550 Comm: syz-executor122 No contaminado 5.16.0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897 Código: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016 RAX: 00 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000000 a R12: 0000000000000000 R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0 Seguimiento de llamadas: lock_acquire kernel/locking/lockdep.c:5637 [en línea] +0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 Finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [en línea] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket. c:1864 [en línea] __se_sys_accept net/socket.c:1861 [en línea] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f177cd8b8e9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX : ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f177 ce13400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c R13: cde1004 R14: 6d705f706374706d R15: 0000000000022000 Arreglar el problema al omitir explícitamente el socket MPTCP en el estado TCP_LISTEN. • https://git.kernel.org/stable/c/740d798e8767d8a449902b1a1bbc70facfce19b5 https://git.kernel.org/stable/c/1456a0004cc54c58adb2501cb0c95dc8b3c83e9e https://git.kernel.org/stable/c/b0cdc5dbcf2ba0d99785da5aabf1b17943805b8a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47593 – mptcp: clear 'kern' flag from fallback sockets
https://notcve.org/view.php?id=CVE-2021-47593
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: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47592 – net: stmmac: fix tc flower deletion for VLAN priority Rx steering
https://notcve.org/view.php?id=CVE-2021-47592
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix tc flower deletion for VLAN priority Rx steering To replicate the issue:- 1) Add 1 flower filter for VLAN Priority based frame steering:- $ IFDEVNAME=eth0 $ tc qdisc add dev $IFDEVNAME ingress $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ flower vlan_prio 0 hw_tc 0 2) Get the 'pref' id $ tc filter show dev $IFDEVNAME ingress 3) Delete a specific tc flower record (say pref 49151) $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 From dmesg, we will observe kernel NULL pointer ooops [ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 197.171367] #PF: supervisor read access in kernel mode [ 197.171367] #PF: error_code(0x0000) - not-present page [ 197.171367] PGD 0 P4D 0 [ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI <snip> [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac] <snip> [ 197.171367] Call Trace: [ 197.171367] <TASK> [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac] [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac] [ 197.171367] tc_setup_cb_destroy+0xb3/0x180 [ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] The above issue is due to previous incorrect implementation of tc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule() to get struct flow_rule *rule which is no longer valid for tc filter delete operation. struct flow_rule *rule = flow_cls_offload_flow_rule(cls); struct flow_dissector *dissector = rule->match.dissector; So, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for earlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(), this patch introduces stmmac_rfs_entry as driver-side flow_cls_offload record for 'RX frame steering' tc flower, currently used for VLAN priority. The implementation has taken consideration for future extension to include other type RX frame steering such as EtherType based. v2: - Clean up overly extensive backtrace and rewrite git message to better explain the kernel NULL pointer issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: corrija la eliminación de flores tc para la dirección Rx con prioridad de VLAN Para replicar el problema: - 1) Agregue 1 filtro de flores para la dirección de cuadros basada en prioridad de VLAN: - $ IFDEVNAME=eth0 $ tc qdisc agregar dev $IFDEVNAME ingreso $ tc qdisc agregar dev $IFDEVNAME raíz mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc filter add dev $IFDEVNAME parent ffff: protocolo 802.1Q \ flower vlan_prio 0 hw_tc 0 2) Obtener el id 'pref' $ tc filter show dev $IFDEVNAME ingress 3 ) Eliminar un registro de flor tc específico (digamos pref 49151) $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 Desde dmesg, observaremos el puntero NULL del kernel ooops [ 197.170464] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 [ 197.171367] #PF: acceso de lectura de supervisor en modo kernel [ 197.171367] #PF: error_code(0x0000) - página no presente [ 197.171367] PGD 0 P4D 0 [ 197.171367] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac] [ 197.171367] Seguimiento de llamadas: [ 197.171367] [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac] [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac] [ 197.171367] tc_setup_cb_destroy+0xb3/0x180 [ 197.171367] destroy_filter+0x94/0xc0 [cls_flower] El problema anterior se debe a una implementación anterior incorrecta de tc_del_vlan_flow( ), que se muestra a continuación, que usa flow_cls_offload_flow_rule() para obtener la estructura flow_rule *rule que ya no es válida para la operación de eliminación del filtro tc. estructura flow_rule *regla = flow_cls_offload_flow_rule(cls); estructura flow_dissector *dissector = regla->match.dissector; Por lo tanto, para garantizar que tc_del_vlan_flow() elimine el registro VLAN cls correcto para la cola RX configurada anteriormente (configurada por hw_tc) en tc_add_vlan_flow(), este parche introduce stmmac_rfs_entry como registro flow_cls_offload del lado del controlador para la flor tc 'Dirección de trama RX', actualmente utilizada para Prioridad de VLAN. • https://git.kernel.org/stable/c/0e039f5cf86ce2fcb62077a163e7ff3d7b7b7cf3 https://git.kernel.org/stable/c/97cb5c82aa1dd85a39b1bd021c8b5f18af623779 https://git.kernel.org/stable/c/aeb7c75cb77478fdbf821628e9c95c4baa9adc63 https://access.redhat.com/security/cve/CVE-2021-47592 https://bugzilla.redhat.com/show_bug.cgi?id=2293235 • CWE-476: NULL Pointer Dereference •