CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52497 – erofs: fix lz4 inplace decompression
https://notcve.org/view.php?id=CVE-2023-52497
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige la descompresión in situ de lz4 Actualmente, EROFS puede asignar otro búfer comprimido para la descompresión in situ, que se utilizó para manejar los casos en que algunas páginas de datos comprimidos en realidad no están in situ I/ o. Sin embargo, como la mayoría de los algoritmos LZ77 simples, LZ4 espera que los datos comprimidos estén organizados al final del buffer descomprimido y usa explícitamente memmove() para manejar la superposición: ________________________________________________________ |_ dirección de descompresión --> ____ |_ datos comprimidos _| Aunque EROFS organiza los datos comprimidos de esta manera, normalmente asigna dos buffers virtuales individuales, por lo que el orden relativo es incierto. • https://git.kernel.org/stable/c/0ffd71bcc3a03ebb3551661a36052488369c4de9 https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379 https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184 https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847 https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52495 – soc: qcom: pmic_glink_altmode: fix port sanity check
https://notcve.org/view.php?id=CVE-2023-52495
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink_altmode: fix port sanity check The PMIC GLINK altmode driver currently supports at most two ports. Fix the incomplete port sanity check on notifications to avoid accessing and corrupting memory beyond the port array if we ever get a notification for an unsupported port. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: corregir la comprobación de la integridad del puerto el controlador PMIC GLINK altmode actualmente admite como máximo dos puertos. Se corrige la verificación incompleta de la integridad del puerto en las notificaciones para evitar acceder y dañar la memoria más allá del conjunto de puertos si alguna vez recibimos una notificación de un puerto no compatible. • https://git.kernel.org/stable/c/080b4e24852b1d5b66929f69344e6c3eeb963941 https://git.kernel.org/stable/c/532a5557da6892a6b2d5793052e1bce1f4c9e177 https://git.kernel.org/stable/c/d26edf4ee3672cc9828f2a3ffae34086a712574d https://git.kernel.org/stable/c/c4fb7d2eac9ff9bfc35a2e4d40c7169a332416e0 •
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: -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/ •