CVSS: 3.2EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47018 – powerpc/64: Fix the definition of the fixmap area
https://notcve.org/view.php?id=CVE-2021-47018
In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64: corrige la definición del área de fixmap Por el momento, el área de fixmap está definida en la parte superior del espacio de direcciones o justo debajo de KASAN. Esta definición no es válida para PPC64. Para PPC64, utilice la parte superior del espacio de E/S. Debido a dependencias circulares, no es posible incluir asm/fixmap.h en asm/book3s/64/pgtable.h, así que defina un ÁREA de tamaño fijo en la parte superior del espacio de E/S para fixmap y asegúrese durante la compilación de que el El tamaño es lo suficientemente grande. • https://git.kernel.org/stable/c/265c3491c4bc8d40587996d6ee2f447a7ccfb4f3 https://git.kernel.org/stable/c/4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd https://git.kernel.org/stable/c/abb07dc5e8b61ab7b1dde20dd73aa01a3aeb183f https://git.kernel.org/stable/c/a84df7c80bdac598d6ac9268ae578da6928883e8 https://git.kernel.org/stable/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c https://access.redhat.com/security/cve/CVE-2021-47018 https://bugzilla.redhat.com/show_bug.cgi?id=2266594 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47017 – ath10k: Fix a use after free in ath10k_htc_send_bundle
https://notcve.org/view.php?id=CVE-2021-47017
In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix a use after free in ath10k_htc_send_bundle In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: corrige un use after free en ath10k_htc_send_bundle En ath10k_htc_send_bundle, el paquete_skb podría ser liberado por dev_kfree_skb_any(bundle_skb). Pero el paquete_skb lo utiliza más tarde el paquete_skb->len. Como skb_len = bundle_skb->len, mi parche reemplaza bundle_skb->len por skb_len después de que se liberó el paquete_skb. • https://git.kernel.org/stable/c/c8334512f3dd1b94844baca629f9bedca4271593 https://git.kernel.org/stable/c/8bb054fb336f4250002fff4e0b075221c05c3c65 https://git.kernel.org/stable/c/3b1ac40c6012140828caa79e592a438a18ebf71b https://git.kernel.org/stable/c/5e413c0831ff4700d1739db3fa3ae9f859744676 https://git.kernel.org/stable/c/8392df5d7e0b6a7d21440da1fc259f9938f4dec3 •
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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47014 – net/sched: act_ct: fix wild memory access when clearing fragments
https://notcve.org/view.php?id=CVE-2021-47014
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix wild memory access when clearing fragments while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one: KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_ct: corrige el acceso salvaje a la memoria al borrar fragmentos mientras se prueba el reensamblaje/refragmentación usando act_ct, es posible observar un bloqueo como el siguiente: KASAN: tal vez acceso a memoria salvaje en el rango [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comunicaciones: swapper/50 Tainted: GS 5.12.0-rc7+ #424 Nombre de hardware: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01 /17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Código: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 00 00200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 00000000000000000 R09: ffffed1186289350 R10: 00000000 00000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 00000000000000000 R15: ffff888155e02160 FS: 00000000000000000 (0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0 000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: inet_frag_destroy+0xa9/0x150 call_timer_fn +0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 cuando act_ct almacena temporalmente un fragmento de IP, la restauración de skb qdisc cb da como resultado la colocación de datos aleatorios en FR AG_CB() , y esto provoca esos accesos a la memoria "salvajes" más adelante, cuando se purga el rbtree. • https://git.kernel.org/stable/c/ae372cb1750f6c95370f92fe5f5620e0954663ba https://git.kernel.org/stable/c/fbff97eb6f4a94a3f15f685bed604c9adc29ac3e https://git.kernel.org/stable/c/0648941f4c8bbf8b4b6c0b270889ae7aa769b921 https://git.kernel.org/stable/c/f77bd544a6bbe69aa50d9ed09f13494cf36ff806 •
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 •