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: -EPSS: 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/ •
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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52490 – mm: migrate: fix getting incorrect page mapping during page migration
https://notcve.org/view.php?id=CVE-2023-52490
In the Linux kernel, the following vulnerability has been resolved: mm: migrate: fix getting incorrect page mapping during page migration When running stress-ng testing, we found below kernel crash after a few hours: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : dentry_name+0xd8/0x224 lr : pointer+0x22c/0x370 sp : ffff800025f134c0 ...... Call trace: dentry_name+0xd8/0x224 pointer+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprintf+0x2c/0x60 vprintk_store+0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x224 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memory_block_offline+0x44/0xf4 memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ...... After analyzing the vmcore, I found this issue is caused by page migration. The scenario is that, one thread is doing page migration, and we will use the target page's ->mapping field to save 'anon_vma' pointer between page unmap and page move, and now the target page is locked and refcount is 1. Currently, there is another stress-ng thread performing memory hotplug, attempting to offline the target page that is being migrated. It discovers that the refcount of this target page is 1, preventing the offline operation, thus proceeding to dump the page. However, page_mapping() of the target page may return an incorrect file mapping to crash the system in dump_mapping(), since the target page->mapping only saves 'anon_vma' pointer without setting PAGE_MAPPING_ANON flag. There are seveval ways to fix this issue: (1) Setting the PAGE_MAPPING_ANON flag for target page's ->mapping when saving 'anon_vma', but this can confuse PageAnon() for PFN walkers, since the target page has not built mappings yet. (2) Getting the page lock to call page_mapping() in __dump_page() to avoid crashing the system, however, there are still some PFN walkers that call page_mapping() without holding the page lock, such as compaction. (3) Using target page->private field to save the 'anon_vma' pointer and 2 bits page state, just as page->mapping records an anonymous page, which can remove the page_mapping() impact for PFN walkers and also seems a simple way. So I choose option 3 to fix this issue, and this can also fix other potential issues for PFN walkers, such as compaction. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: migrar: se corrigió la asignación de página incorrecta durante la migración de la página Al ejecutar la prueba de estrés, encontramos el siguiente bloqueo del kernel después de unas horas: No se puede manejar la desreferencia del puntero NULL del kernel en virtual dirección 0000000000000000 pc: dentry_name+0xd8/0x224 lr: puntero+0x22c/0x370 sp: ffff800025f134c0 ...... Rastreo de llamadas: dentry_name+0xd8/0x224 puntero+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprint f+0x2c/0x60 vprintk_store+ 0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x22 4 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memoria_block_offline+ 0x44/0xf4 Memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ...... • https://git.kernel.org/stable/c/64c8902ed4418317cd416c566f896bd4a92b2efc https://git.kernel.org/stable/c/9128bfbc5c80d8f4874dd0a0424d1f5fb010df1b https://git.kernel.org/stable/c/3889a418b6eb9a1113fb989aaadecf2f64964767 https://git.kernel.org/stable/c/d1adb25df7111de83b64655a80b5a135adbded61 •
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') •