CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47163 – tipc: wait and exit until all work queues are done
https://notcve.org/view.php?id=CVE-2021-47163
In the Linux kernel, the following vulnerability has been resolved: tipc: wait and exit until all work queues are done On some host, a crash could be triggered simply by repeating these commands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? • https://git.kernel.org/stable/c/d0f91938bede204a343473792529e0db7d599836 https://git.kernel.org/stable/c/d1f76dfadaf8f47ed1753f97dbcbd41c16215ffa https://git.kernel.org/stable/c/5195ec5e365a2a9331bfeb585b613a6e94f98dba https://git.kernel.org/stable/c/b9f5b7ad4ac3af006443f535b1ce7bff1d130d7d https://git.kernel.org/stable/c/04c26faa51d1e2fe71cf13c45791f5174c37f986 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47162 – tipc: skb_linearize the head skb when reassembling msgs
https://notcve.org/view.php?id=CVE-2021-47162
In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when reassembling msgs It's not a good idea to append the frag skb to a skb's frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices: [] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] process_one_work+0x1a7/0x360 [] worker_thread+0x30/0x390 [] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram_iter+0x3b/0x90 [] tipc_recvmsg+0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] kernel BUG at mm/slub.c:305! • https://git.kernel.org/stable/c/45c8b7b175ceb2d542e0fe15247377bf3bce29ec https://git.kernel.org/stable/c/d45ed6c1ff20d3640a31f03816ca2d48fb7d6f22 https://git.kernel.org/stable/c/c19282fd54a19e4651a4e67836cd842082546677 https://git.kernel.org/stable/c/b2c8d28c34b3070407cb1741f9ba3f15d0284b8b https://git.kernel.org/stable/c/5489f30bb78ff0dafb4229a69632afc2ba20765c https://git.kernel.org/stable/c/436d650d374329a591c30339a91fa5078052ed1e https://git.kernel.org/stable/c/4b1761898861117c97066aea6c58f68a7787f0bf https://git.kernel.org/stable/c/64d17ec9f1ded042c4b188d15734f3348 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47161 – spi: spi-fsl-dspi: Fix a resource leak in an error handling path
https://notcve.org/view.php?id=CVE-2021-47161
In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix a resource leak in an error handling path 'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the error handling path of the probe function, as already done in the remove function En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: spi-fsl-dspi: reparar una fuga de recursos en una ruta de manejo de errores 'dspi_request_dma()' debe deshacerse mediante una llamada 'dspi_release_dma()' en la ruta de manejo de errores de la función de sonda, como ya se hizo en la función de eliminación • https://git.kernel.org/stable/c/90ba37033cb94207e97c4ced9be575770438213b https://git.kernel.org/stable/c/10a089bae827ec30ad9b6cb7048020a62fae0cfa https://git.kernel.org/stable/c/00450ed03a17143e2433b461a656ef9cd17c2f1d https://git.kernel.org/stable/c/15d1cc4b4b585f9a2ce72c52cca004d5d735bdf1 https://git.kernel.org/stable/c/fe6921e3b8451a537e01c031b8212366bb386e3e https://git.kernel.org/stable/c/12391be4724acc9269e1845ccbd881df37de4b56 https://git.kernel.org/stable/c/680ec0549a055eb464dce6ffb4bfb736ef87236e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47160 – net: dsa: mt7530: fix VLAN traffic leaks
https://notcve.org/view.php?id=CVE-2021-47160
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mt7530: fix VLAN traffic leaks PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but was not reset when it is disabled, which may cause traffic leaks: ip link add br0 type bridge vlan_filtering 1 ip link add br1 type bridge vlan_filtering 1 ip link set swp0 master br0 ip link set swp1 master br1 ip link set br0 type bridge vlan_filtering 0 ip link set br1 type bridge vlan_filtering 0 # traffic in br0 and br1 will start leaking to each other As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the PCR_MATRIX write from mt7530_port_set_vlan_aware. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: dsa: mt7530: corregir fugas de tráfico de VLAN El campo PCR_MATRIX se configuró en todos 1 cuando el filtrado de VLAN está habilitado, pero no se restableció cuando está deshabilitado, lo que puede causar fugas de tráfico: enlace ip agregar puente tipo br0 vlan_filtering 1 enlace ip agregar puente tipo br1 vlan_filtering 1 conjunto de enlaces ip swp0 master br0 conjunto de enlaces ip swp1 maestro br1 conjunto de enlaces ip br0 puente tipo vlan_filtering 0 conjunto de enlaces ip br1 tipo puente vlan_filtering 0 # tráfico en br0 y br1 comenzarán a filtrarse entre sí. Como port_bridge_{add,del} ha configurado PCR_MATRIX correctamente, elimine la escritura PCR_MATRIX de mt7530_port_set_vlan_aware. • https://git.kernel.org/stable/c/83163f7dca5684816d01c8ccf4857aa74801e7b7 https://git.kernel.org/stable/c/ae389812733b1b1e8e07fcc238e41db166b5c78d https://git.kernel.org/stable/c/4fe4e1f48ba119bdbc7c897c83b04ba0d08f5488 https://git.kernel.org/stable/c/b91117b66fe875723a4e79ec6263526fffdb44d2 https://git.kernel.org/stable/c/82ae35b6c14feae5f216913d5b433e143c756d4e https://git.kernel.org/stable/c/474a2ddaa192777522a7499784f1d60691cd831a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47159 – net: dsa: fix a crash if ->get_sset_count() fails
https://notcve.org/view.php?id=CVE-2021-47159
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix a crash if ->get_sset_count() fails If ds->ops->get_sset_count() fails then it "count" is a negative error code such as -EOPNOTSUPP. Because "i" is an unsigned int, the negative error code is type promoted to a very high value and the loop will corrupt memory until the system crashes. Fix this by checking for error codes and changing the type of "i" to just int. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: corrige un bloqueo si ->get_sset_count() falla. Si ds->ops->get_sset_count() falla, entonces "count" es un código de error negativo como - EOPNOTSUPP. Debido a que "i" es un int sin signo, el código de error negativo se promociona a un valor muy alto y el bucle corromperá la memoria hasta que el sistema falle. • https://git.kernel.org/stable/c/badf3ada60ab8f76f9488dc8f5c0c57f70682f5a https://git.kernel.org/stable/c/0f2cb08c57edefb0e7b5045e0e3e9980a3d3aa37 https://git.kernel.org/stable/c/ce5355f140a7987011388c7e30c4f8fbe180d3e8 https://git.kernel.org/stable/c/caff86f85512b8e0d9830e8b8b0dfe13c68ce5b6 https://git.kernel.org/stable/c/7b22466648a4f8e3e94f57ca428d1531866d1373 https://git.kernel.org/stable/c/a269333fa5c0c8e53c92b5a28a6076a28cde3e83 •