CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47015 – bnxt_en: Fix RX consumer index logic in the error path.
https://notcve.org/view.php?id=CVE-2021-47015
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la lógica del índice del consumidor RX en la ruta del error. • https://git.kernel.org/stable/c/a1b0e4e684e9c300b9e759b46cb7a0147e61ddff https://git.kernel.org/stable/c/8e302e8e10b05165ed21273539a1e6a83ab93e9e https://git.kernel.org/stable/c/46281ee85b651b0df686001651b965d17b8e2c67 https://git.kernel.org/stable/c/d2d055a554036b0240f296743942b8111fd4ce97 https://git.kernel.org/stable/c/aecbbae850ede49183fa0b73c7445531a47669cf https://git.kernel.org/stable/c/b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847 https://git.kernel.org/stable/c/4fcaad2b7dac3f16704f8118c7e481024ddbd3ed https://git.kernel.org/stable/c/e187ef83c04a5d23e68d39cfdff1a1931 •
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: 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: 8EXPL: 0CVE-2021-47006 – ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook
https://notcve.org/view.php?id=CVE-2021-47006
In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9064/1: hw_breakpoint: no comprobar directamente el gancho overflow_handler del evento. el commit 1879445dfa7b ("perf/core: establecer el valor predeterminado del evento ::overflow_handler()") establece un valor predeterminado event->overflow_handler en perf_event_alloc(), y reemplace check event->overflow_handler con is_default_overflow_handler(), pero falta uno. Actualmente, bp->overflow_handler no puede ser NULL. Como resultado, enable_single_step() no siempre se invoca. Comentarios de Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ • https://git.kernel.org/stable/c/1879445dfa7bbd6fe21b09c5cc72f4934798afed https://git.kernel.org/stable/c/555a70f7fff03bd669123487905c47ae27dbdaac https://git.kernel.org/stable/c/ed1f67465327cec4457bb988775245b199da86e6 https://git.kernel.org/stable/c/a9938d6d78a238d6ab8de57a4d3dcf77adceb9bb https://git.kernel.org/stable/c/3ed8832aeaa9a37b0fc386bb72ff604352567c80 https://git.kernel.org/stable/c/630146203108bf6b8934eec0dfdb3e46dcb917de https://git.kernel.org/stable/c/7eeacc6728c5478e3c01bc82a1f08958eaa12366 https://git.kernel.org/stable/c/dabe299425b1a53a69461fed7ac8922ea •