CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-27043 – media: edia: dvbdev: fix a use-after-free
https://notcve.org/view.php?id=CVE-2024-27043
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: edia: dvbdev: corregir un use-after-free En dvb_register_device, *pdvbdev se establece igual a dvbdev, que se libera en varias rutas de manejo de errores. • https://git.kernel.org/stable/c/b61901024776b25ce7b8edc31bb1757c7382a88e https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856 https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086 https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644 https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712 https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62 https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f •
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.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26982 – Squashfs: check the inode number is not the invalid value of zero
https://notcve.org/view.php?id=CVE-2024-26982
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Squashfs: comprobar que el número de inodo no sea el valor no válido de cero. • https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5 https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395 https://access.redhat.com/security/cve/CVE-2024-26982 https://bugzilla.redhat.com/show_bug.cgi?id=2278337 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26980 – ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
https://notcve.org/view.php?id=CVE-2024-26980
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb2_allocate_rsp_buf Si ->ProtocolId es SMB2_TRANSFORM_PROTO_NUM, se podría omitir la validación del tamaño de la solicitud smb2. Si el tamaño de la solicitud es menor que sizeof (struct smb2_query_info_req), la lectura de losa fuera de los límites puede ocurrir en smb2_allocate_rsp_buf(). Este parche asigna un búfer de respuesta después de descifrar la solicitud de transformación. smb3_decrypt_req() validará el tamaño de la solicitud de transformación y evitará la losa fuera de los límites en smb2_allocate_rsp_buf(). • https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325 https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248 https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1 https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085 https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20 •