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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38630 – watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
https://notcve.org/view.php?id=CVE-2024-38630
In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314 https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4 •
CVSS: 5.6EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38627 – stm class: Fix a double free in stm_register_device()
https://notcve.org/view.php?id=CVE-2024-38627
In the Linux kernel, the following vulnerability has been resolved: stm class: Fix a double free in stm_register_device() The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clase stm: corrige un doble free en stm_register_device() La llamada put_device(&stm->dev) activará stm_device_release() que libera "stm" para que vfree(stm) en el La siguiente línea es un doble libre. A vulnerability was found in the Linux kernel's stm class, where an improper memory management sequence in stm_register_device() could lead to a double-free error. This issue occurs when the put_device(&stm->dev) call triggers stm_device_release() to free "stm", making the subsequent vfree(stm) call redundant and potentially harmful. • https://git.kernel.org/stable/c/389b6699a2aa0b457aa69986e9ddf39f3b4030fd https://git.kernel.org/stable/c/b0351a51ffda593b2b1b35dd0c00a73505edb256 https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931 https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695 https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36 https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247 https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21e • CWE-415: Double Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38621 – media: stk1160: fix bounds checking in stk1160_copy_video()
https://notcve.org/view.php?id=CVE-2024-38621
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". • https://git.kernel.org/stable/c/9cb2173e6ea8f2948bd1367c93083a2500fcf08f https://git.kernel.org/stable/c/f6a392266276730bea893b55d12940e32a25f56a https://git.kernel.org/stable/c/ecf4ddc3aee8ade504c4d36b7b4053ce6093e200 https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7 https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd https://git.kernel.org/stable/c/b504518a397059e1d55c521ba0ea2b545a6c4b52 https://git.kernel.org/stable/c/d410017a7181cb55e4a5c810b32b75e4416c6808 https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca8 •