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: 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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47005 – PCI: endpoint: Fix NULL pointer dereference for ->get_features()
https://notcve.org/view.php?id=CVE-2021-47005
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix NULL pointer dereference for ->get_features() get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0 ]--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: endpoint: corrigió la desreferencia del puntero NULL para ->get_features() las operaciones get_features de pci_epc_ops pueden devolver NULL, lo que provoca la desreferencia del puntero NULL en la función pci_epf_test_alloc_space. Agreguemos una verificación del puntero pci_epc_feature en pci_epf_test_bind antes de acceder a él para evitar dicha desreferencia del puntero NULL y devolvamos -ENOTSUPP en caso de que no se encuentre pci_epc_feature. Cuando no se aplica el parche y las funciones de EPC no se implementan en el controlador de la plataforma, vemos el siguiente volcado debido a la desreferencia del puntero NULL del kernel. Rastreo de llamadas: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys _symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70 /0x88 el0_svc+0x8/0x640 Código: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ final de seguimiento a438e3c5a24f9df0 ]--- • https://git.kernel.org/stable/c/2c04c5b8eef797dca99699cfb55ff42dd3c12c23 https://git.kernel.org/stable/c/bbed83d7060e07a5d309104d25a00f0a24441428 https://git.kernel.org/stable/c/679ebad058b8168f10e63876d63b0877fd2fe784 https://git.kernel.org/stable/c/0169d4f0bee44fdfef908c13ed21fcb326c38695 https://git.kernel.org/stable/c/6613bc2301ba291a1c5a90e1dc24cf3edf223c03 •