CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52661 – drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe()
https://notcve.org/view.php?id=CVE-2023-52661
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: rgb: corrige la falta de clk_put() en las rutas de manejo de errores de tegra_dc_rgb_probe(). Si clk_get_sys(..., "pll_d2_out0") falla, la llamada clk_get_sys() debe deshacerse. Agregue el clk_put que falta y una nueva etiqueta 'put_pll_d_out0' en la ruta de manejo de errores y úsela. • https://git.kernel.org/stable/c/0c921b6d4ba06bc899fd84d3ce1c1afd3d00bc1c https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7 https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101 https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3 https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35826 – block: Fix page refcounts for unaligned buffers in __bio_release_pages()
https://notcve.org/view.php?id=CVE-2024-35826
In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: corregidos recuentos de páginas para buffers no alineados en __bio_release_pages() Corrige un número incorrecto de páginas que se liberan para buffers que no comienzan al principio de una página. • https://git.kernel.org/stable/c/9025ee1079291fac79c7fcc20086e9f0015f86f4 https://git.kernel.org/stable/c/8955324cc9f93304efe163120038b38c36c09fba https://git.kernel.org/stable/c/d198c15d181cc9d580f0f2c25150b077d1d49c1a https://git.kernel.org/stable/c/1b151e2435fc3a9b10c8946c6aebe9f3e1938c55 https://git.kernel.org/stable/c/d2d0b95ca1b5fefa3deed444a803c9f809db66cf https://git.kernel.org/stable/c/3f4e660144edb053886fc80f587a71ad7afc2ad6 https://git.kernel.org/stable/c/bfc0647791d7a8f3e178a896a26c4ef7794876b7 https://git.kernel.org/stable/c/0f2dca516541032fe47a1236c852f58ed •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-35825 – usb: gadget: ncm: Fix handling of zero block length packets
https://notcve.org/view.php?id=CVE-2024-35825
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. • https://git.kernel.org/stable/c/ff3ba016263ee93a1c6209bf5ab1599de7ab1512 https://git.kernel.org/stable/c/e7ca00f35d8a17af1ae19d529193ebc21bfda164 https://git.kernel.org/stable/c/17c653d4913bbc50d284aa96cf12bfc63e41ee5c https://git.kernel.org/stable/c/7014807fb7efa169a47a7a0a0a41d2c513925de0 https://git.kernel.org/stable/c/49fbc18378ae72a47feabee97fdb86f3cea09765 https://git.kernel.org/stable/c/427694cfaafa565a3db5c5ea71df6bc095dca92f https://git.kernel.org/stable/c/5bdf93a2f5459f944b416b188178ca4a92fd206f https://git.kernel.org/stable/c/4bf1a9d20c65b9e80ca4b171267103f8d •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35824 – misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume
https://notcve.org/view.php?id=CVE-2024-35824
In the Linux kernel, the following vulnerability has been resolved: misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: lis3lv02d_i2c: corrige que los reguladores se activen/desactiven dos veces al suspender/reanudar Cuando no está configurado para reactivación, lis3lv02d_i2c_suspend() llamará a lis3lv02d_poweroff() incluso si el dispositivo ya ha sido desactivado por el controlador de suspensión de tiempo de ejecución y si está configurado para reactivación y el dispositivo está suspendido en tiempo de ejecución en este punto, no se vuelve a activar para que sirva como fuente de activación. Antes de la confirmación b1b9f7a49440 ("misc: lis3lv02d_i2c: Agregar configuración faltante de la devolución de llamada reg_ctrl"), lis3lv02d_poweroff() fallaba al deshabilitar los reguladores, lo que como efecto secundario hizo que llamar a poweroff() dos veces fuera correcto. Ahora que poweroff() desactiva correctamente los reguladores, al hacer esto dos veces se activa una ADVERTENCIA() en el núcleo del regulador: desactivaciones desequilibradas para regulador ficticio ADVERTENCIA: CPU: 1 PID: 92 en drivers/regulator/core.c:2999 _regulator_disable .. • https://git.kernel.org/stable/c/2c1164ad927e62f122b151493bb183bc11dab8f8 https://git.kernel.org/stable/c/1229ce1c4acd36f5af97c996420defc43daca635 https://git.kernel.org/stable/c/755182e1e8667272a082506a2a20b4cdd78ab4c2 https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7 https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325 https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45 https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d https://access.redhat.com/security/cve/CVE-2024-35824 •
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 •