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-2024-26607 – drm/bridge: sii902x: Fix probing race issue
https://notcve.org/view.php?id=CVE-2024-26607
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/bridge: sii902x: soluciona el problema de carrera de sondeo. Rara vez se ha observado un fallo de desreferencia de puntero nulo en plataformas TI que utilizan el puente sii9022: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53 .292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/ 0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_f bdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216 ] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] very_probe+0x188/0x3 c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c /0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] dispositivo_initial_probe+0x14/0 x20 [ 53.373314] dispositivo_probe_bus+0xb0/0xb4 [ 53.377145] función_trabajo_probe_diferida+0xcc/0x124 [ 53.381757] Process_one_work+0x1f0/0x518 [ 53.385770] Worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 El problema aquí es el siguiente: - tids s, pero se pospone ya que sii902x todavía está desaparecido. - sii902x comienza a sondear e ingresa sii902x_init(). - sii902x llama a drm_bridge_add(). Ahora el puente sii902x está listo desde la perspectiva de DRM. - sii902x llama a sii902x_audio_codec_init() y platform_device_register_data() - El registro del dispositivo de plataforma de audio provoca el sondeo de los dispositivos diferidos. - sondas tidss, que eventualmente provocan que se llame a sii902x_bridge_get_edid(). - sii902x_bridge_get_edid() intenta usar i2c para leer el edit. • https://git.kernel.org/stable/c/21d808405fe49028036932dd969920f4fee4f481 https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076 https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1 https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9 •
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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52483 – mctp: perform route lookups under a RCU read-side lock
https://notcve.org/view.php?id=CVE-2023-52483
In the Linux kernel, the following vulnerability has been resolved: mctp: perform route lookups under a RCU read-side lock Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net's route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer. Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree. The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates. Based on an analysis from Sili Luo <rootlab@huawei.com>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mctp: realiza búsquedas de rutas bajo un bloqueo del lado de lectura de RCU. Nuestras búsquedas de rutas actuales (mctp_route_lookup y mctp_route_lookup_null) atraviesan la lista de rutas de la red sin que se mantenga el bloqueo de lectura de RCU. Esto significa que la búsqueda de ruta está sujeta a preferencia, lo que resulta en una posible expiración del período de gracia y, por lo tanto, en un eventual kfree() mientras todavía tenemos el puntero de ruta. • https://git.kernel.org/stable/c/889b7da23abf92faf34491df95733bda63639e32 https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67 https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4 https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c •