CVSS: 6.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26610 – wifi: iwlwifi: fix a memory corruption
https://notcve.org/view.php?id=CVE-2024-26610
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: corrige una corrupción de memoria iwl_fw_ini_trigger_tlv::data es un puntero a un __le32, lo que significa que si copiamos a iwl_fw_ini_trigger_tlv::data + offset mientras el offset está en bytes, escribiremos más allá del búfer. A memory corruption flaw was found in the Linux kernel Intel Wireless WiFi Next Gen AGN module. This issue could allow a local user to crash the system. • https://git.kernel.org/stable/c/cf29c5b66b9f83939367d90679eb68cdfa2f0356 https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32 https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67 https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-680: Integer Overflow to Buffer Overflow •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52498 – PM: sleep: Fix possible deadlocks in core system-wide PM code
https://notcve.org/view.php?id=CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: suspensión: soluciona posibles bloqueos en el código PM de todo el sistema central. Se informa que en situaciones de poca memoria, el código central de reanudación de todo el sistema se bloquea porque async_schedule_dev() ejecuta su el argumento funciona sincrónicamente si no puede asignar memoria (y no solo en ese caso) y esa función intenta adquirir un mutex que ya está retenido. La ejecución de la función de argumento sincrónicamente desde dpm_async_fn() también puede ser problemática por razones de pedido (puede causar que la devolución de llamada de currículum de un dispositivo consumidor se invoque antes que la de un dispositivo proveedor requerido, por ejemplo). • https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0 https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34 https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7 https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
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: 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/ •