CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26999 – serial/pmac_zilog: Remove flawed mitigation for rx irq flood
https://notcve.org/view.php?id=CVE-2024-26999
In the Linux kernel, the following vulnerability has been resolved: serial/pmac_zilog: Remove flawed mitigation for rx irq flood The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port. Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below. A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3 https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928 https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7 https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26998 – serial: core: Clearing the circular buffer before NULLifying it
https://notcve.org/view.php?id=CVE-2024-26998
In the Linux kernel, the following vulnerability has been resolved: serial: core: Clearing the circular buffer before NULLifying it The circular buffer is NULLified in uart_tty_port_shutdown() under the spin lock. However, the PM or other timer based callbacks may still trigger after this event without knowning that buffer pointer is not valid. Since the serial code is a bit inconsistent in checking the buffer state (some rely on the head-tail positions, some on the buffer pointer), it's better to have both aligned, i.e. buffer pointer to be NULL and head-tail possitions to be the same, meaning it's empty. This will prevent asynchronous calls to dereference NULL pointer as reported recently in 8250 case: BUG: kernel NULL pointer dereference, address: 00000cf5 Workqueue: pm pm_runtime_work EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) ... ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) __start_tx (drivers/tty/serial/8250/8250_port.c:1551) serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654) serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63) __rpm_callback (drivers/base/power/runtime.c:393) ? serial_port_remove (drivers/tty/serial/serial_port.c:50) rpm_suspend (drivers/base/power/runtime.c:447) The proposed change will prevent ->start_tx() to be called during suspend on shut down port. • https://git.kernel.org/stable/c/434beb66368d4fb4d3119c2116b9398500adbf47 https://git.kernel.org/stable/c/43066e32227ecde674e8ae1fcdd4a1ede67680c2 https://git.kernel.org/stable/c/a629a9b2f7699314a4abe8fbc37b0ee667b60f33 https://git.kernel.org/stable/c/7ae7104d54342433a3a73975f6569beefdd86350 https://git.kernel.org/stable/c/bb1118905e875c111d7ccef9aee86ac5e4e7f985 https://git.kernel.org/stable/c/9cf7ea2eeb745213dc2a04103e426b960e807940 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26997 – usb: dwc2: host: Fix dereference issue in DDMA completion flow.
https://notcve.org/view.php?id=CVE-2024-26997
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: host: Fix dereference issue in DDMA completion flow. Fixed variable dereference issue in DDMA completion flow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: host: solucionó el problema de desreferencia en el flujo de finalización de DDMA. Se solucionó el problema de desreferencia variable en el flujo de finalización de DDMA. • https://git.kernel.org/stable/c/dca1dc1e99e09e7b8eaccb55d6aecb87d9cb8ecd https://git.kernel.org/stable/c/693bbbccd9c774adacaf03ae9fcbb33b66b1ffc4 https://git.kernel.org/stable/c/db4fa0c8e811676a7bfe8363a01e70ee601e75f7 https://git.kernel.org/stable/c/32d3f2f108ebcaf9bd9fc06095c776cb73add034 https://git.kernel.org/stable/c/bc48eb1b53ce977d17d51caa574bd81064a117a2 https://git.kernel.org/stable/c/8d310e5d702c903a7ac95fb5dd248f046b39db00 https://git.kernel.org/stable/c/8b7c57ab6f6bc6bfee87e929cab6e6dac351606b https://git.kernel.org/stable/c/c4046e703e0083c8d2031cce02f2479e9 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26996 – usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
https://notcve.org/view.php?id=CVE-2024-26996
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_ncm: corrige el objeto UAF ncm al volver a vincularlo después del error de transporte usb ep Cuando la función ncm está funcionando y luego detiene la interfaz usb0 para desconectar el enlace, se llama a eth_stop() . En este punto, accidentalmente, si ocurre un error de transporte USB en usb_ep_enable(), es posible que 'in_ep' y/o 'out_ep' no estén habilitados. Después de eso, se llama a ncm_disable() para deshabilitar ncm unbind, pero nunca se llama a gether_disconnect() ya que 'in_ep' no está habilitado. • https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93 https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3 https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7 https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e •
CVSS: 5.9EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26994 – speakup: Avoid crash on very long word
https://notcve.org/view.php?id=CVE-2024-26994
In the Linux kernel, the following vulnerability has been resolved: speakup: Avoid crash on very long word In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer. En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: Speakup: Evitar crash en palabras muy largas En caso de que una consola esté configurada muy grande y contenga una palabra muy larga (>256 caracteres), tenemos que detenernos antes de la longitud de la palabra. búfer de palabras. • https://git.kernel.org/stable/c/c6e3fd22cd538365bfeb82997d5b89562e077d42 https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222 https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8 https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595 https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd460 •