CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52486 – drm: Don't unref the same fb many times by mistake due to deadlock handling
https://notcve.org/view.php?id=CVE-2023-52486
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm: No desreferenciar el mismo fb muchas veces por error debido al manejo de interbloqueos Si obtenemos un punto muerto después de la búsqueda de fb en drm_mode_page_flip_ioctl() procedemos a desreferenciar el fb y luego Vuelva a intentarlo todo desde arriba. Pero nos olvidamos de restablecer el puntero fb a NULL, por lo que si obtenemos otro error durante el reintento, antes de la búsqueda de fb, procedemos a desref el mismo fb nuevamente sin haber obtenido otra referencia. • https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229 https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7 https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105 https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551 https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0 https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76f • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52485 – drm/amd/display: Wake DMCUB before sending a command
https://notcve.org/view.php?id=CVE-2023-52485
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before sending a command [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we're done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: activa DMCUB antes de enviar un comando [Por qué] Podemos quedarnos quietos intentando enviar comandos cuando DMCUB no está encendido. [Cómo] Para funciones que se ejecutan dentro de un contexto de DC o bloqueo de DC, podemos ajustar las llamadas directas a dm_execute_dmub_cmd/list con código que salga de las optimizaciones de energía inactivas y se vuelva a permitir una vez que hayamos terminado con el envío del comando en caso de éxito. Para envíos directos de DM, el DM deberá gestionar la secuencia de entrada/salida manualmente. No podemos invocar un comando DMCUB directamente dentro del asistente de ejecución de DM o podemos bloquearnos. • https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009 https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52484 – iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range
https://notcve.org/view.php?id=CVE-2023-52484
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/arm-smmu-v3: Corrección del bloqueo suave activado por arm_smmu_mm_invalidate_range Cuando se ejecuta un caso SVA, se activa el siguiente bloqueo suave: ----------- -------------------------------------------------- ------- perro guardián: ERROR: bloqueo suave - ¡CPU#244 bloqueada durante 26 segundos! • https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264 https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429 https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6 •
CVSS: 6.7EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52482 – x86/srso: Add SRSO mitigation for Hygon processors
https://notcve.org/view.php?id=CVE-2023-52482
In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/srso: agregue mitigación SRSO para procesadores Hygon. Agregue mitigación para la vulnerabilidad de desbordamiento de pila de retorno especulativo que también existe en los procesadores Hygon. A vulnerability was found in the Linux kernel, where the Hygon x86 processor is susceptible to a speculative return stack overflow. • https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37 https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96 https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4 https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2023-52482 https://bugzilla.redhat.com/show_bug.cgi?id=2267028 • CWE-562: Return of Stack Variable Address •
CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52481 – arm64: errata: Add Cortex-A520 speculative unprivileged load workaround
https://notcve.org/view.php?id=CVE-2023-52481
In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. • https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25 https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513 •