CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38637 – greybus: lights: check return of get_channel_from_mode
https://notcve.org/view.php?id=CVE-2024-38637
In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: luces: verificar el retorno de get_channel_from_mode Si no se encuentra el canal para el nodo dado, devolvemos nulo de get_channel_from_mode. Asegúrese de validar el puntero de retorno antes de usarlo en dos de los lugares que faltan. Esto se informó originalmente en [0]: Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru • https://git.kernel.org/stable/c/2870b52bae4c81823ffcb3ed2b0626fb39d64f48 https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21 https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850 https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2 https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8 https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38 https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ec •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-38635 – soundwire: cadence: fix invalid PDI offset
https://notcve.org/view.php?id=CVE-2024-38635
In the Linux kernel, the following vulnerability has been resolved: soundwire: cadence: fix invalid PDI offset For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT. This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds. A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well. A follow-up patch completely removes this useless offset. • https://git.kernel.org/stable/c/002364b2d594a9afc0385c09e00994c510b1d089 https://git.kernel.org/stable/c/fd4bcb991ebaf0d1813d81d9983cfa99f9ef5328 https://git.kernel.org/stable/c/902f6d656441a511ac25c6cffce74496db10a078 https://git.kernel.org/stable/c/2ebcaa0e5db9b6044bb487ae1cf41bc601761567 https://git.kernel.org/stable/c/7eeef1e935d23db5265233d92395bd5c648a4021 https://git.kernel.org/stable/c/4e99103f757cdf636c6ee860994a19a346a11785 https://git.kernel.org/stable/c/8ee1b439b1540ae543149b15a2a61b9dff937d91 https://access.redhat.com/security/cve/CVE-2024-38635 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38634 – serial: max3100: Lock port->lock when calling uart_handle_cts_change()
https://notcve.org/view.php?id=CVE-2024-38634
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Lock port->lock when calling uart_handle_cts_change() uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: max3100: Bloquear puerto->bloquear al llamar a uart_handle_cts_change() uart_handle_cts_change() debe llamarse con el bloqueo de puerto tomado. Dado que lo ejecutamos en un trabajo separado, el bloqueo puede No se tomará en el momento de correr. Asegúrese de que se tome haciéndolo explícitamente. • https://git.kernel.org/stable/c/7831d56b0a3544cbb6f82f76c34ca95e24d5b676 https://git.kernel.org/stable/c/44b38924135d2093e2ec1812969464845dd66dc9 https://git.kernel.org/stable/c/ea9b35372b58ac2931bfc1d5bc25e839d1221e30 https://git.kernel.org/stable/c/cc121e3722a0a2c8f716ef991e5425b180a5fb94 https://git.kernel.org/stable/c/78dbda51bb4241b88a52d71620f06231a341f9ba https://git.kernel.org/stable/c/8296bb9e5925b6634259c5d4daee88f0cc0884ec https://git.kernel.org/stable/c/93df2fba6c7dfa9a2f08546ea9a5ca4728758458 https://git.kernel.org/stable/c/865b30c8661924ee9145f442bf32cea54 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38633 – serial: max3100: Update uart_driver_registered on driver removal
https://notcve.org/view.php?id=CVE-2024-38633
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: max3100: actualización uart_driver_registered al eliminar el controlador La eliminación del último dispositivo MAX3100 desencadena la eliminación del controlador. Sin embargo, el código no actualiza la variable global respectiva y después del ciclo insmod — rmmod — insmod, el kernel falla: max3100 spi-PRP0001:01: max3100_probe: agregando el puerto 0 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000408... • https://git.kernel.org/stable/c/7831d56b0a3544cbb6f82f76c34ca95e24d5b676 https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003 https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72 https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752 https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00 https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762 https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a •
CVSS: 5.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38632 – vfio/pci: fix potential memory leak in vfio_intx_enable()
https://notcve.org/view.php?id=CVE-2024-38632
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: fix potential memory leak in vfio_intx_enable() If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak. • https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3 https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899 https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897 https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834 https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d2374 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •