CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27001 – comedi: vmk80xx: fix incomplete endpoint checking
https://notcve.org/view.php?id=CVE-2024-27001
In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix incomplete endpoint checking While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them. Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present. This patch has not been tested on real hardware. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ... Similar issue also found by Syzkaller: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige la verificación de endpoints incompleta Si bien vmk80xx tiene implementada la verificación de endpoints, algunas cosas pueden pasar desapercibidas. Dependiendo del modelo de hardware, las URB pueden tener un tipo masivo o de interrupción, y la versión actual de la función vmk80xx_find_usb_endpoints() no lo tiene completamente en cuenta. • https://git.kernel.org/stable/c/49253d542cc0f5f771dc254d248162a2a666649d https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9 https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54 https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696 https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f6 •
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: 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 •
CVSS: 5.5EPSS: 0%CPEs: 14EXPL: 0CVE-2024-26993 – fs: sysfs: Fix reference leak in sysfs_break_active_protection()
https://notcve.org/view.php?id=CVE-2024-26993
In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: sysfs: corrige la fuga de referencia en sysfs_break_active_protection() La rutina sysfs_break_active_protection() tiene una fuga de referencia obvia en su ruta de error. Si la llamada a kernfs_find_and_get() falla, entonces kn será NULL, por lo que no se llamará a la rutina complementaria sysfs_unbreak_active_protection() (y solo causaría una infracción de acceso al intentar eliminar la referencia a kn->parent si se llamara). • https://git.kernel.org/stable/c/2afc9166f79b8f6da5f347f48515215ceee4ae37 https://git.kernel.org/stable/c/e8a37b2fd5b5087bec6cbbf6946ee3caa712953b https://git.kernel.org/stable/c/a6abc93760dd07fcd29760b70e6e7520f22cb288 https://git.kernel.org/stable/c/461a6385e58e8247e6ba2005aa5d1b8d980ee4a2 https://git.kernel.org/stable/c/8a5e02a0f46ea33ed19e48e096a8e8d28e73d10a https://git.kernel.org/stable/c/c984f4d1d40a2f349503b3faf946502ccbf02f9f https://git.kernel.org/stable/c/807d1d299a04e9ad9a9dac55419c1137a105254b https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c •