CVSS: 4.4EPSS: 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 https://access.redhat.com/security/cve/CVE-2023 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/9ff2d260b25df6fe1341a79113d88fecf6bd553e 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/3c12466b6b7bf1e56f9b32c366a3d83d8 •
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/ •