CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27059 – USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
https://notcve.org/view.php?id=CVE-2024-27059
In the Linux kernel, the following vulnerability has been resolved: USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer. Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: almacenamiento-usb: evita el error de división por 0 en isd200_ata_command El subcontrolador isd200 en almacenamiento-usb utiliza los valores HEADS y SECTORES en la información de ID de ATA para calcular el cilindro y valores principales al crear un CDB para comandos LEER o ESCRIBIR. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34 https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133 https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964 https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325 https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c6 •
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: 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 •