CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47008 – KVM: SVM: Make sure GHCB is mapped before updating
https://notcve.org/view.php?id=CVE-2021-47008
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Make sure GHCB is mapped before updating Access to the GHCB is mainly in the VMGEXIT path and it is known that the GHCB will be mapped. But there are two paths where it is possible the GHCB might not be mapped. The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform the caller of the AP Reset Hold NAE event that a SIPI has been delivered. However, if a SIPI is performed without a corresponding AP Reset Hold, then the GHCB might not be mapped (depending on the previous VMEXIT), which will result in a NULL pointer dereference. The svm_complete_emulated_msr() routine will update the GHCB to inform the caller of a RDMSR/WRMSR operation about any errors. While it is likely that the GHCB will be mapped in this situation, add a safe guard in this path to be certain a NULL pointer dereference is not encountered. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: asegúrese de que GHCB esté mapeado antes de actualizar. El acceso al GHCB se encuentra principalmente en la ruta VMGEXIT y se sabe que el GHCB será mapeado. • https://git.kernel.org/stable/c/647daca25d24fb6eadc7b6cd680ad3e6eed0f3d5 https://git.kernel.org/stable/c/fb9e14f4f8217a0980f8da2c8ff70dee058cbe47 https://git.kernel.org/stable/c/fd722a57fe0b80133dacae4e1c852ee4212f9b2e https://git.kernel.org/stable/c/a3ba26ecfb569f4aa3f867e80c02aa65f20aadad •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47007 – f2fs: fix panic during f2fs_resize_fs()
https://notcve.org/view.php?id=CVE-2021-47007
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix panic during f2fs_resize_fs() f2fs_resize_fs() hangs in below callstack with testcase: - mkfs 16GB image & mount image - dd 8GB fileA - dd 8GB fileB - sync - rm fileA - sync - resize filesystem to 8GB kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el pánico durante f2fs_resize_fs() f2fs_resize_fs() se bloquea en la pila de llamadas debajo con el caso de prueba: - imagen mkfs de 16 GB y montaje de imagen - dd archivo A de 8 GB - agrega archivo B de 8 GB - sincronización - archivo rm A - sincronización - cambiar el tamaño del sistema de archivos al kernel de 8 GB ¡ERROR en segment.c:2484! Seguimiento de llamadas: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page +0x392/0x850 [f2fs] mover_página_datos+0x233/0x320 [f2fs] ] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioct l+0x8e/0xd0 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 La raíz Porque olvidamos verificar si tenemos suficiente espacio en el sistema de archivos redimensionado para almacenar todos los bloques válidos en el sistema de archivos antes de cambiar el tamaño, entonces el asignador se quedará sin espacio durante la migración de bloques en free_segment_range(). • https://git.kernel.org/stable/c/b4b10061ef98c583bcf82a4200703fbaa98c18dc https://git.kernel.org/stable/c/1c20a4896409f5ca1c770e1880c33d0a28a8b10f https://git.kernel.org/stable/c/860afd680d9cc1dabd61cda3cd246f60aa1eb705 https://git.kernel.org/stable/c/822054e5026c43b1dd60cf387dd999e95ee2ecc2 https://git.kernel.org/stable/c/3ab0598e6d860ef49d029943ba80f627c15c15d6 •
CVSS: 5.5EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47004 – f2fs: fix to avoid touching checkpointed data in get_victim()
https://notcve.org/view.php?id=CVE-2021-47004
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid touching checkpointed data in get_victim() In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar tocar datos con puntos de control en get_victim() En el modo de desactivación de CP, hay dos problemas al usar LFS o SSR | Modo AT_SSR para seleccionar a la víctima: 1. LFS está configurado para buscar la sección de origen durante la GC, la víctima no debe tener datos de puntos de control, ya que después de la GC, la sección no se puede liberar para su reutilización. • https://git.kernel.org/stable/c/4354994f097d068a894aa1a0860da54571df3582 https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d https://git.kernel.org/stable/c/1e116f87825f01a6380286472196882746b16f63 https://git.kernel.org/stable/c/211372b2571520e394b56b431a0705586013b3ff https://git.kernel.org/stable/c/61461fc921b756ae16e64243f72af2bfc2e620db •