CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35828 – wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
https://notcve.org/view.php?id=CVE-2024-35828
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: libertas: arreglados algunas memleaks en lbs_allocate_cmd_buffer() En la declaración for de lbs_allocate_cmd_buffer(), si falló la asignación de cmdarray[i].cmdbuf, tanto cmdarray como cmdarray[i] Es necesario liberar ].cmdbuf. De lo contrario, habrá fugas de memoria en lbs_allocate_cmd_buffer(). • https://git.kernel.org/stable/c/876c9d3aeb989cf1961f2c228d309ba5dcfb1172 https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186 https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7 https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2 https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9 https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3 https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23ed •
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: 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 •