CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47034 – powerpc/64s: Fix pte update for kernel memory on radix
https://notcve.org/view.php?id=CVE-2021-47034
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. • https://git.kernel.org/stable/c/f1cb8f9beba8699dd1b4518418191499e53f7b17 https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7 https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301 https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47024 – vsock/virtio: free queued packets when closing socket
https://notcve.org/view.php?id=CVE-2021-47024
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vsock/virtio: paquetes libres en cola al cerrar el socket Según lo informado por syzbot [1], hay una pérdida de memoria al cerrar el socket. Resolvimos parcialmente este problema con el compromiso ac03046ece2b ("vsock/virtio: paquetes libres durante el lanzamiento del socket"), pero nos olvidamos de vaciar la cola RX cuando el trabajo programado cierra definitivamente el socket. Para evitar problemas futuros, usemos el nuevo virtio_transport_remove_sock() para drenar la cola RX antes de eliminar el socket de las listas af_vsock llamando a vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug? • https://git.kernel.org/stable/c/ac03046ece2b158ebd204dfc4896fd9f39f0e6c8 https://git.kernel.org/stable/c/4ea082cd3c400cd5bb36a7beb7e441bf3e29350d https://git.kernel.org/stable/c/4e539fa2dec4db3405e47002f2878aa4a99eb68b https://git.kernel.org/stable/c/4af8a327aeba102aaa9b78f3451f725bc590b237 https://git.kernel.org/stable/c/51adb8ebe8c1d80528fc2ea863cfea9d32d2c52b https://git.kernel.org/stable/c/7d29c9ad0ed525c1b10e29cfca4fb1eece1e93fb https://git.kernel.org/stable/c/b605673b523fe33abeafb2136759bcbc9c1e6ebf https://git.kernel.org/stable/c/27691665145e74a45034a9dccf1150cf1 •
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: 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 •