CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52489 – mm/sparsemem: fix race in accessing memory_section->usage
https://notcve.org/view.php?id=CVE-2023-52489
In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. • https://git.kernel.org/stable/c/f46edbd1b1516da1fb34c917775168d5df576f78 https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529 https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97 https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7 https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52488 – serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO
https://notcve.org/view.php?id=CVE-2023-52488
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses. • https://git.kernel.org/stable/c/dfeae619d781dee61666d5551b93ba3be755a86b https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611 https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169 https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573 https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23 https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b https://lists.debian.org/debian-lts-announce/2024/06/ •
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 •