CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52494 – bus: mhi: host: Add alignment check for event ring read pointer
https://notcve.org/view.php?id=CVE-2023-52494
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check for event ring read pointer Though we do check the event ring read pointer by "is_valid_ring_ptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for event ring read pointer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: agregar verificación de alineación para el puntero de lectura del anillo de eventos. Aunque verificamos el puntero de lectura del anillo de eventos mediante "is_valid_ring_ptr" para asegurarnos de que esté en el rango del búfer, pero existe otro riesgo de que el puntero no esté alineado. Dado que esperamos que los elementos del anillo de eventos estén alineados con 128 bits (struct mhi_ring_element), un puntero de lectura no alineado podría provocar múltiples problemas como DoS o corrupción de la memoria del búfer del anillo. • https://git.kernel.org/stable/c/ec32332df7645e0ba463a08d483fe97665167071 https://git.kernel.org/stable/c/a1d2bd164c1c78f87968b7883964175ec41c32ae https://git.kernel.org/stable/c/fd5f40fc887485a8b9a6806a640a0d8e0ef1afb6 https://git.kernel.org/stable/c/76879a980cd5ede4cb9a638999fb80d37bc09db5 https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08 https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551 https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010 https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52493 – bus: mhi: host: Drop chan lock before queuing buffers
https://notcve.org/view.php?id=CVE-2023-52493
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: Eliminar el bloqueo de canal antes de poner en cola los búferes asegúrese de que los bloqueos de lectura y escritura para el canal no se tomen en sucesión eliminando el bloqueo de lectura de parse_xfer_event() de manera que se pueda realizar una devolución de llamada dado al cliente puede potencialmente poner en cola los búferes y adquirir el bloqueo de escritura en ese proceso. Cualquier puesta en cola de búferes debe realizarse sin adquirir el bloqueo de lectura del canal, ya que puede generar múltiples bloqueos y un bloqueo suave. [mani: etiqueta de correcciones agregada y copia estable] • https://git.kernel.org/stable/c/1d3173a3bae7039b765a0956e3e4bf846dbaacb8 https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690 https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830 https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52492 – dmaengine: fix NULL pointer in channel unregistration function
https://notcve.org/view.php?id=CVE-2023-52492
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: corrige el puntero NULL en la función de cancelación del registro del canal __dma_async_device_channel_register() puede fallar. En caso de falla, chan->local se libera (con free_percpu()) y chan->local se anula. Cuando se llama a dma_async_device_unregister() (debido a una API administrada o intencionalmente por el controlador del controlador DMA), los canales se anulan incondicionalmente, lo que lleva a este puntero NULL: [1.318693] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000d0 [...] [ 1.484499] Seguimiento de llamadas: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Mire la ruta de error de la función dma_async_device_register(), cancelación del registro del dispositivo La ración se realiza sólo si chan->local es no nulo. • https://git.kernel.org/stable/c/d2fb0a0438384fee08a418025f743913020033ce https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17 https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79 https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08 https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0 https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52491 – media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
https://notcve.org/view.php?id=CVE-2023-52491
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mtk-jpeg: Se corrigió el error de use-after-free debido al manejo de la ruta de error en mtk_jpeg_dec_device_run En mtk_jpeg_probe, &jpeg->job_timeout_work está vinculado con mtk_jpeg_job_timeout_work. • https://git.kernel.org/stable/c/b2f0d2724ba477d326e9d654d4db1c93e98f8b93 https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9 https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590 https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6 https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7 https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e https://lists.debian.org/debian-lts-announce/2024/06/ •
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') •