CVSS: 7.0EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47013 – net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
https://notcve.org/view.php?id=CVE-2021-47013
In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:emac/emac-mac: Se corrige un uso after free en emac_mac_tx_buf_send En emac_mac_tx_buf_send, llama a emac_tx_fill_tpd(..,skb,..). Si ocurre algún error en emac_tx_fill_tpd(), el skb se liberará mediante dev_kfree_skb(skb) en la rama de error de emac_tx_fill_tpd(). • https://git.kernel.org/stable/c/b9b17debc69d27cd55e21ee51a5ba7fc50a426cf https://git.kernel.org/stable/c/c7f75d11fe72913d2619f97b2334b083cd7bb955 https://git.kernel.org/stable/c/dc1b438a35773d030be0ee80d9c635c3e558a322 https://git.kernel.org/stable/c/16d8c44be52e3650917736d45f5904384a9da834 https://git.kernel.org/stable/c/55fcdd1258faaecca74b91b88cc0921f9edd775d https://git.kernel.org/stable/c/9dc373f74097edd0e35f3393d6248eda8d1ba99d https://git.kernel.org/stable/c/8c06f34785068b87e2b560534c77c163d6c6dca7 https://git.kernel.org/stable/c/e407495ba6788a67d1bd41714158c079e • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47012 – RDMA/siw: Fix a use after free in siw_alloc_mr
https://notcve.org/view.php?id=CVE-2021-47012
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix a use after free in siw_alloc_mr Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: RDMA/siw: Corrige un use after free en siw_alloc_mr Nuestro analizador de código informó un UAF. • https://git.kernel.org/stable/c/2251334dcac9eb337575d8767e2a6a7e81848f7f https://git.kernel.org/stable/c/30b9e92d0b5e5d5dc1101ab856c17009537cbca4 https://git.kernel.org/stable/c/608a4b90ece039940e9425ee2b39c8beff27e00c https://git.kernel.org/stable/c/3e22b88e02c194f6c80867abfef5cc09383461f4 https://git.kernel.org/stable/c/ad9ce7188432650469a6c7625bf479f5ed0b6155 https://git.kernel.org/stable/c/3093ee182f01689b89e9f8797b321603e5de4f63 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47011 – mm: memcontrol: slab: fix obtain a reference to a freeing memcg
https://notcve.org/view.php?id=CVE-2021-47011
In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a reference to a freeing memcg Patch series "Use obj_cgroup APIs to charge kmem pages", v5. Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. • https://git.kernel.org/stable/c/26f54dac15640c65ec69867e182de7be708ea389 https://git.kernel.org/stable/c/3de7d4f25a7438f09fef4e71ef111f1805cd8e7c https://git.kernel.org/stable/c/31df8bc4d3feca9f9c6b2cd06fd64a111ae1a0e6 https://git.kernel.org/stable/c/89b1ed358e01e1b0417f5d3b0082359a23355552 https://git.kernel.org/stable/c/c3ae6a3f3ca4f02f6ccddf213c027302586580d0 https://git.kernel.org/stable/c/9f38f03ae8d5f57371b71aa6b4275765b65454fd •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47010 – net: Only allow init netns to set default tcp cong to a restricted algo
https://notcve.org/view.php?id=CVE-2021-47010
In the Linux kernel, the following vulnerability has been resolved: net: Only allow init netns to set default tcp cong to a restricted algo tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: solo permite que init netns establezca la cong tcp predeterminada en un algoritmo restringido tcp_set_default_congestion_control() es seguro para netns porque escribe en &net->ipv4.tcp_congestion_control, pero también establece ca->flags |= TCP_CONG_NON_RESTRICTED que no tiene espacio de nombres. Esto tiene el efecto secundario no deseado de cambiar el sistema global net.ipv4.tcp_allowed_congestion_control, a pesar de que es de solo lectura: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resuelva esta "fuga" de netns solo permite que las redes de inicio establezcan el algoritmo predeterminado en uno restringido. Esta restricción podría eliminarse si tcp_allowed_congestion_control tuviera un espacio de nombres en el futuro. Este error se descubrió con https://github.com/JonathonReinhart/linux-netns-sysctl-verify • https://git.kernel.org/stable/c/6670e152447732ba90626f36dfc015a13fbf150e https://git.kernel.org/stable/c/992de06308d9a9584d59b96d294ac676f924e437 https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68 https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42 https://git.kernel.org/stable/c/efe1532a6e1a8e3c343d04fff510f0ed80328f9c https://git.kernel.org/stable/c/e7d7bedd507bb732e600403b7a96f9fe48d0ca31 https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b4897884493 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47009 – KEYS: trusted: Fix memory leak on object td
https://notcve.org/view.php?id=CVE-2021-47009
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak on object td Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LLAVES: confiable: corrige la pérdida de memoria en el objeto td. Dos rutas de retorno de error no liberan el objeto asignado td, lo que provoca una pérdida de memoria. Solucione este problema regresando a través de la ruta de retorno de error que segura el td. Corrige la advertencia de clang scan-build: seguridad/claves/trusted-keys/trusted_tpm1.c:496:10: advertencia: Posible pérdida de memoria [unix.Malloc] • https://git.kernel.org/stable/c/9d83cc1a1e7f494aedee2aa108e801d11525fccf https://git.kernel.org/stable/c/8cfc8d62942105e5df4a20a15b24da077a6b24ef https://git.kernel.org/stable/c/5df16caada3fba3b21cb09b85cdedf99507f4ec1 https://git.kernel.org/stable/c/31c9a4b24d86cbb36ff0d7a085725a3b4f0138c8 https://git.kernel.org/stable/c/1c4031014106aff48e1e686e40101c31eab5d44c https://git.kernel.org/stable/c/3e24fbd37e72e8a67b74991970fecc82d14f57af https://git.kernel.org/stable/c/83a775d5f9bfda95b1c295f95a3a041a40c7f321 •