CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-27061 – crypto: sun8i-ce - Fix use after free in unprepare
https://notcve.org/view.php?id=CVE-2024-27061
In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Fix use after free in unprepare sun8i_ce_cipher_unprepare should be called before crypto_finalize_skcipher_request, because client callbacks may immediately free memory, that isn't needed anymore. But it will be used by unprepare after free. Before removing prepare/unprepare callbacks it was handled by crypto engine in crypto_finalize_request. Usually that results in a pointer dereference problem during a in crypto selftest. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000 [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP This problem is detected by KASAN as well. ================================================================== BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373 Hardware name: Pine64 PinePhone (1.2) (DT) Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_load8+0x9c/0xc0 sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] crypto_pump_work+0x354/0x620 [crypto_engine] kthread_worker_fn+0x244/0x498 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x38 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x74/0x1d0 alg_test_skcipher+0x90/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Freed by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x60 __kasan_slab_free+0x100/0x170 slab_free_freelist_hook+0xd4/0x1e8 __kmem_cache_free+0x15c/0x290 kfree+0x74/0x100 kfree_sensitive+0x80/0xb0 alg_test_skcipher+0x12c/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 The buggy address belongs to the object at ffff00000dcdc000 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: sun8i-ce: se corrige el use after free en unprepare. Se debe llamar a sun8i_ce_cipher_unprepare antes de crypto_finalize_skcipher_request, porque las devoluciones de llamada del cliente pueden liberar inmediatamente memoria, que ya no es necesaria. Pero será utilizado por los que no estén preparados después de ser gratuito. • https://git.kernel.org/stable/c/4136212ab18eb3dce6efb6e18108765c36708f71 https://git.kernel.org/stable/c/dc60b25540c82fc4baa95d1458ae96ead21859e0 https://git.kernel.org/stable/c/51a7d338c212e0640b1aca52ba6590d5bea49879 https://git.kernel.org/stable/c/183420038444547c149a0fc5f58e792c2752860c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27060 – thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()
https://notcve.org/view.php?id=CVE-2024-27060
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix NULL pointer dereference in tb_port_update_credits() Olliver reported that his system crashes when plugging in Thunderbolt 1 device: BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt] Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? • https://git.kernel.org/stable/c/81af2952e60603d12415e1a6fd200f8073a2ad8b https://git.kernel.org/stable/c/ce64ba1f6ec3439e4b4d880b4db99673f4507228 https://git.kernel.org/stable/c/d3d17e23d1a0d1f959b4fa55b35f1802d9c584fa https://git.kernel.org/stable/c/440fba897c5ae32d7df1f1d609dbb19e2bba7fbb •
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: 4.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27058 – tmpfs: fix race on handling dquot rbtree
https://notcve.org/view.php?id=CVE-2024-27058
In the Linux kernel, the following vulnerability has been resolved: tmpfs: fix race on handling dquot rbtree A syzkaller reproducer found a race while attempting to remove dquot information from the rb tree. Fetching the rb_tree root node must also be protected by the dqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot() will trigger a warning because it couldn't find a node in the tree, when the real reason was the root node changing before the search starts: Thread 1 Thread 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - fetch ROOT - Fetch ROOT - acquire dqio_sem - wait dqio_sem - do something, triger a tree rebalance - release dqio_sem - acquire dqio_sem - start searching for the node, but from the wrong location, missing the node, and triggering a warning. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tmpfs: corrige la ejecución al manejar dquot rbtree Un reproductor syzkaller encontró una ejecución al intentar eliminar información de dquot del árbol rb. La recuperación del nodo raíz de rb_tree también debe estar protegida por dqopt->dqio_sem; de lo contrario, si se da el momento adecuado, shmem_release_dquot() activará una advertencia porque no pudo encontrar un nodo en el árbol, cuando la verdadera razón era el nodo raíz. cambiando antes de que comience la búsqueda: Hilo 1 Hilo 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - buscar ROOT - Obtener ROOT - adquirir dqio_sem - esperar dqio_sem - hacer algo, activar un reequilibrio de árbol - liberar dqio_sem - adquirir dqio_sem - comienza a buscar el nodo, pero desde la ubicación incorrecta, pierde el nodo y genera una advertencia. • https://git.kernel.org/stable/c/eafc474e202978ac735c551d5ee1eb8c02e2be54 https://git.kernel.org/stable/c/c7077f43f30d817d10a9f8245e51576ac114b2f0 https://git.kernel.org/stable/c/617d55b90e73c7b4aa2733ca6cc3f9b72d1124bb https://git.kernel.org/stable/c/f82f184874d2761ebaa60dccf577921a0dbb3810 https://git.kernel.org/stable/c/0a69b6b3a026543bc215ccc866d0aea5579e6ce2 •
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 •