CVSS: 8.4EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47313 – cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init
https://notcve.org/view.php?id=CVE-2021-47313
In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init It's a classic example of memleak, we allocate something, we fail and never free the resources. Make sure we free all resources on policy ->init() failures. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: arregla potencial memleak en cppc_cpufreq_cpu_init Es un ejemplo clásico de memleak, asignamos algo, fallamos y nunca liberamos los recursos. Asegúrese de liberar todos los recursos en fallos de política ->init(). • https://git.kernel.org/stable/c/a28b2bfc099c6b9caa6ef697660408e076a32019 https://git.kernel.org/stable/c/b775383355755885b19d2acef977f1ca132e80a3 https://git.kernel.org/stable/c/e1b2b2b61d30d7ce057ec17237c217d152ed97f2 https://git.kernel.org/stable/c/fe2535a44904a77615a3af8e8fd7dafb98fb0e1b • CWE-400: Uncontrolled Resource Consumption •
CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 0CVE-2021-47312 – netfilter: nf_tables: Fix dereference of null pointer flow
https://notcve.org/view.php?id=CVE-2021-47312
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix dereference of null pointer flow In the case where chain->flags & NFT_CHAIN_HW_OFFLOAD is false then nft_flow_rule_create is not called and flow is NULL. The subsequent error handling execution via label err_destroy_flow_rule will lead to a null pointer dereference on flow when calling nft_flow_rule_destroy. Since the error path to err_destroy_flow_rule has to cater for null and non-null flows, only call nft_flow_rule_destroy if flow is non-null to fix this issue. Addresses-Coverity: ("Explicity null dereference") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige la desreferencia del flujo de puntero null. En el caso de que chain->flags & NFT_CHAIN_HW_OFFLOAD sea falso, no se llama a nft_flow_rule_create y el flujo es NULL. La ejecución posterior del manejo de errores a través de la etiqueta err_destroy_flow_rule dará lugar a una desreferencia del puntero null en el flujo al llamar a nft_flow_rule_destroy. Dado que la ruta de error a err_destroy_flow_rule tiene que atender flujos nulos y no nulos, solo llame a nft_flow_rule_destroy si el flujo no es nulo para solucionar este problema. • https://git.kernel.org/stable/c/09b1f676e2e0bbff67c568672c565c6f31470157 https://git.kernel.org/stable/c/70a5a1950cca02c5cd161bb3846b4d983eed97d3 https://git.kernel.org/stable/c/4ca041f919f13783b0b03894783deee00dbca19a • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47311 – net: qcom/emac: fix UAF in emac_remove
https://notcve.org/view.php?id=CVE-2021-47311
In the Linux kernel, the following vulnerability has been resolved: net: qcom/emac: fix UAF in emac_remove adpt is netdev private data and it cannot be used after free_netdev() call. Using adpt after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: qcom/emac: corrige UAF en emac_remove adpt son datos privados de netdev y no se pueden usar después de la llamada a free_netdev(). Usar adpt después de free_netdev() puede causar un error en UAF. • https://git.kernel.org/stable/c/54e19bc74f3380d414681762ceed9f7245bc6a6e https://git.kernel.org/stable/c/4d04a42b926e682140776e54188f4a44f1f01a81 https://git.kernel.org/stable/c/b1e091331920f8fbfc747dcbd16263fcd71abb2d https://git.kernel.org/stable/c/11e9d163d631198bb3eb41a677a61b499516c0f7 https://git.kernel.org/stable/c/2b70ca92847c619d6264c7372ef74fcbfd1e048c https://git.kernel.org/stable/c/b560521eca03d0a2db6093a5a632cbdd0a0cf833 https://git.kernel.org/stable/c/8a225a6e07a57a1538d53637cb3d82bd3e477839 https://git.kernel.org/stable/c/ad297cd2db8953e2202970e9504cab247 • CWE-416: Use After Free •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47310 – net: ti: fix UAF in tlan_remove_one
https://notcve.org/view.php?id=CVE-2021-47310
In the Linux kernel, the following vulnerability has been resolved: net: ti: fix UAF in tlan_remove_one priv is netdev private data and it cannot be used after free_netdev() call. Using priv after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ti: corrige UAF en tlan_remove_one priv son datos privados de netdev y no se pueden usar después de la llamada free_netdev(). Usar priv después de free_netdev() puede causar un error en UAF. • https://git.kernel.org/stable/c/1e0a8b13d35510e711fdf72e9a3e30bcb2bd49fa https://git.kernel.org/stable/c/a18a8d9cfbb112ad72e625372849adc3986fd6bf https://git.kernel.org/stable/c/c263ae8c7e4c482387de5e6c89e213f8173fe8b6 https://git.kernel.org/stable/c/0538b0ab7d2c396e385694228c7cdcd2d2c514e9 https://git.kernel.org/stable/c/a0a817b2d308fac090a05cbbe80988e073ac5193 https://git.kernel.org/stable/c/b7e5563f2a7862a9e4796abb9908b092f677e3c1 https://git.kernel.org/stable/c/f2a062fcfe1d6f1b0a86fa76ae21c277d65f4405 https://git.kernel.org/stable/c/93efab0ef2a607fff9166d447c4035f98 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47309 – net: validate lwtstate->data before returning from skb_tunnel_info()
https://notcve.org/view.php?id=CVE-2021-47309
In the Linux kernel, the following vulnerability has been resolved: net: validate lwtstate->data before returning from skb_tunnel_info() skb_tunnel_info() returns pointer of lwtstate->data as ip_tunnel_info type without validation. lwtstate->data can have various types such as mpls_iptunnel_encap, etc and these are not compatible. So skb_tunnel_info() should validate before returning that pointer. Splat looks like: BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan] Read of size 2 at addr ffff888106ec2698 by task ping/811 CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195 Call Trace: dump_stack_lvl+0x56/0x7b print_address_description.constprop.8.cold.13+0x13/0x2ee ? vxlan_get_route+0x418/0x4b0 [vxlan] ? vxlan_get_route+0x418/0x4b0 [vxlan] kasan_report.cold.14+0x83/0xdf ? vxlan_get_route+0x418/0x4b0 [vxlan] vxlan_get_route+0x418/0x4b0 [vxlan] [ ... ] vxlan_xmit_one+0x148b/0x32b0 [vxlan] [ ... ] vxlan_xmit+0x25c5/0x4780 [vxlan] [ ... ] dev_hard_start_xmit+0x1ae/0x6e0 __dev_queue_xmit+0x1f39/0x31a0 [ ... ] neigh_xmit+0x2f9/0x940 mpls_xmit+0x911/0x1600 [mpls_iptunnel] lwtunnel_xmit+0x18f/0x450 ip_finish_output2+0x867/0x2040 [ ... ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: validar lwtstate->data antes de regresar de skb_tunnel_info() skb_tunnel_info() devuelve un puntero de lwtstate->data como tipo ip_tunnel_info sin validación. lwtstate->data puede tener varios tipos como mpls_iptunnel_encap, etc. y estos no son compatibles. Entonces skb_tunnel_info() debería validarse antes de devolver ese puntero. • https://git.kernel.org/stable/c/61adedf3e3f1d3f032c5a6a299978d91eff6d555 https://git.kernel.org/stable/c/e7f3c9df40515a6c6b46f36c4c94cf48a043f887 https://git.kernel.org/stable/c/b61d327cd3cc5ea591f3bf751dd11e034f388bb5 https://git.kernel.org/stable/c/83bdcfbd968bcc91a0632b7b625e4a9b0cba5e0d https://git.kernel.org/stable/c/8bb1589c89e61e3b182dd546f1021928ebb5c2a6 https://git.kernel.org/stable/c/8aa13a86964cdec4fd969ef677c6614ff068641a https://git.kernel.org/stable/c/2179d96ec702cc33ead02a9ce40ece599b8538c5 https://git.kernel.org/stable/c/a915379594f1e045421635c6316d8f3ff •