CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35823 – vt: fix unicode buffer corruption when deleting characters
https://notcve.org/view.php?id=CVE-2024-35823
In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vt: corregida la corrupción del búfer Unicode al eliminar caracteres. Este es el mismo problema que se solucionó para el búfer de texto VGA en la confirmación 39cdb68c64d8 ("vt: corrige la superposición de memoria al eliminar caracteres en el búfer "). La solución también es la misma, es decir, reemplazar memcpy() con memmove() debido a la superposición de buffers. • https://git.kernel.org/stable/c/81732c3b2fede049a692e58a7ceabb6d18ffb18c https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90 https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51 https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35822 – usb: udc: remove warning when queue disabled ep
https://notcve.org/view.php?id=CVE-2024-35822
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug(). • https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8 https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290 https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f0257 •
CVSS: 7.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35821 – ubifs: Set page uptodate in the correct place
https://notcve.org/view.php?id=CVE-2024-35821
In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: establece la actualización de la página en el lugar correcto. Las lecturas de la caché de la página no tienen bloqueo, por lo que configurar la actualización de la página recién asignada antes de que la sobrescribamos con los datos que se supone que debe contener lo hará. permitir que un lector simultáneo vea datos antiguos. Mueva la llamada a SetPageUptodate a ubifs_write_end(), que es después de que copiamos los nuevos datos en la página. • https://git.kernel.org/stable/c/1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310 https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3 https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3 https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa • CWE-772: Missing Release of Resource after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-35819 – soc: fsl: qbman: Use raw spinlock for cgr_lock
https://notcve.org/view.php?id=CVE-2024-35819
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc: fsl: qbman: use spinlock sin formato para cgr_lock smp_call_function siempre ejecuta su devolución de llamada en un contexto IRQ duro, incluso en PREEMPT_RT, donde los spinlocks pueden dormir. Por lo tanto, necesitamos usar un spinlock sin formato para cgr_lock para asegurarnos de que no estamos esperando una tarea inactiva. Aunque este error ha existido por un tiempo, no fue evidente hasta la confirmación ef2a8d5478b9 ("net: dpaa: Ajustar la profundidad de la cola al cambiar la velocidad") que invoca smp_call_function_single a través de qman_update_cgr_safe cada vez que un enlace sube o baja. • https://git.kernel.org/stable/c/96f413f47677366e0ae03797409bfcc4151dbf9e https://git.kernel.org/stable/c/a85c525bbff4d7467d7f0ab6fed8e2f787b073d6 https://git.kernel.org/stable/c/29cd9c2d1f428c281962135ea046a9d7bda88d14 https://git.kernel.org/stable/c/5b10a404419f0532ef3ba990c12bebe118adb6d7 https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02 https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59 https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1 https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35818 – LoongArch: Define the __io_aw() hook as mmiowb()
https://notcve.org/view.php?id=CVE-2024-35818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). • https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167 https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd •