CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-27057 – ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend
https://notcve.org/view.php?id=CVE-2024-27057
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: ipc4-pcm: workaround para firmware bloqueado en suspensión del sistema Cuando el sistema se suspende mientras el audio está activo, se invoca sof_ipc4_pcm_hw_free() para restablecer las canalizaciones desde durante la suspensión el DSP está apagado, las transmisiones se reiniciarán después de reanudarse. Si el firmware falla mientras se ejecuta el audio (o cuando reiniciamos la transmisión antes de suspenderla), entonces sof_ipc4_set_multi_pipeline_state() fallará con un error de IPC y se interrumpirá el cambio de estado. Esto provocará una desalineación entre el estado del kernel y del firmware en el siguiente arranque del DSP, lo que provocará errores devueltos por el firmware para los mensajes IPC, lo que eventualmente provocará un error en la reanudación del audio. Al cerrar la transmisión, los errores se ignoran, por lo que el estado del kernel se corregirá en el siguiente inicio del DSP, es decir, en el segundo inicio después del pánico del DSP. • https://git.kernel.org/stable/c/3cac6eebea9b4bc5f041e157e45c76e212ad6759 https://git.kernel.org/stable/c/d153e8b154f9746ac969c85a4e6474760453647c https://git.kernel.org/stable/c/c40aad7c81e5fba34b70123ed7ce3397fa62a4d2 https://access.redhat.com/security/cve/CVE-2024-27057 https://bugzilla.redhat.com/show_bug.cgi?id=2278406 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27056 – wifi: iwlwifi: mvm: ensure offloading TID queue exists
https://notcve.org/view.php?id=CVE-2024-27056
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: ensure offloading TID queue exists The resume code path assumes that the TX queue for the offloading TID has been configured. At resume time it then tries to sync the write pointer as it may have been updated by the firmware. In the unusual event that no packets have been send on TID 0, the queue will not have been allocated and this causes a crash. Fix this by ensuring the queue exist at suspend time. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: asegúrese de que exista la cola de descarga TID La ruta del código de reanudación supone que se ha configurado la cola de TX para la descarga de TID. En el momento de la reanudación, intenta sincronizar el puntero de escritura, ya que es posible que el firmware lo haya actualizado. • https://git.kernel.org/stable/c/ed35a509390ef4011ea2226da5dd6f62b73873b5 https://git.kernel.org/stable/c/78f65fbf421a61894c14a1b91fe2fb4437b3fe5f https://access.redhat.com/security/cve/CVE-2024-27056 https://bugzilla.redhat.com/show_bug.cgi?id=2278409 •
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 •