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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47591 – mptcp: remove tcp ulp setsockopt support
https://notcve.org/view.php?id=CVE-2021-47591
In the Linux kernel, the following vulnerability has been resolved: mptcp: remove tcp ulp setsockopt support TCP_ULP setsockopt cannot be used for mptcp because its already used internally to plumb subflow (tcp) sockets to the mptcp layer. syzbot managed to trigger a crash for mptcp connections that are in fallback mode: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline] [..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638 Remove support for TCP_ULP setsockopt. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: elimina el soporte de tcp ulp setsockopt TCP_ULP setsockopt no se puede usar para mptcp porque ya se usa internamente para conectar sockets de subflujo (tcp) a la capa mptcp. syzbot logró desencadenar un bloqueo para las conexiones mptcp que están en modo alternativo: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2- syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [en línea] [..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [en línea] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c: 160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638 Elimina la compatibilidad con TCP_ULP setsockopt. • https://git.kernel.org/stable/c/d9e4c129181004ec94b315b0c9db5eeb09da75e6 https://git.kernel.org/stable/c/3de0c86d42f841d1d64f316cd949e65c566f0734 https://git.kernel.org/stable/c/404cd9a22150f24acf23a8df2ad0c094ba379f57 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47590 – mptcp: fix deadlock in __mptcp_push_pending()
https://notcve.org/view.php?id=CVE-2021-47590
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix deadlock in __mptcp_push_pending() __mptcp_push_pending() may call mptcp_flush_join_list() with subflow socket lock held. If such call hits mptcp_sockopt_sync_all() then subsequently __mptcp_sockopt_sync() could try to lock the subflow socket for itself, causing a deadlock. sysrq: Show Blocked State task:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000 Call Trace: <TASK> __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? • https://git.kernel.org/stable/c/1b3e7ede1365a24db1b4fd837e58a595f52fa4ad https://git.kernel.org/stable/c/23311b92755ffa9087332d1bb8c71c0f6a10cc08 https://git.kernel.org/stable/c/3d79e3756ca90f7a6087b77b62c1d9c0801e0820 https://access.redhat.com/security/cve/CVE-2021-47590 https://bugzilla.redhat.com/show_bug.cgi?id=2293237 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47589 – igbvf: fix double free in `igbvf_probe`
https://notcve.org/view.php?id=CVE-2021-47589
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 •