Page 555 of 4283 results (0.010 seconds)

CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/neonbs - fix out-of-bounds access on short input The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON glue code will copy inputs shorter than 16 bytes into a temporary buffer, given that this is a rare occurrence and it is not worth the effort to work around this in the asm code. The fallback from the bit-sliced NEON version fails to take this into account, potentially resulting in out-of-bounds accesses. So clone the same workaround, and use a temp buffer for short in/outputs. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: arm64/neonbs: corrige el acceso fuera de los límites en entradas cortas. La implementación de bits de AES-CTR opera en bloques de 128 bytes y recurrirá al Versión NEON simple para bloques finales o entradas que, para empezar, tienen menos de 128 bytes. Llamará directamente al asistente simple NEON asm, que realiza todos los accesos a la memoria en gránulos de 16 bytes (el tamaño de un registro NEON). • https://git.kernel.org/stable/c/fc074e130051015e39245a4241956ff122e2f465 https://git.kernel.org/stable/c/034e2d70b5c7f578200ad09955aeb2aa65d1164a https://git.kernel.org/stable/c/1291d278b5574819a7266568ce4c28bce9438705 https://git.kernel.org/stable/c/9e8ecd4908b53941ab6f0f51584ab80c6c6606c4 https://git.kernel.org/stable/c/1c0cf6d19690141002889d72622b90fc01562ce4 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: fsl-qdma: init irq after reg inicialización Inicialice qDMA irqs después de configurar los registros para que las interrupciones que puedan haber estado pendientes de un kernel primario no sean procesadas por el controlador irq antes de que esté listo y cause pánico con el siguiente rastreo: Rastreo de llamadas: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x 178 generic_handle_irq+0x24/0x38 __handle_domain_irq +0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/ 0xe8 fsl_qdma_probe+0x4d4/0xca8 plataforma_drv_probe+0x50/0xa0 very_probe+0xe0/0x3f8 driver_probe_device +0x64/0x130 dispositivo_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x 44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable +0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18 • https://git.kernel.org/stable/c/b092529e0aa09829a6404424ce167bf3ce3235e2 https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478 https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1 https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99 https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8 https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmci: stm32: corregir la advertencia de asignaciones superpuestas de la API DMA Al activar CONFIG_DMA_API_DEBUG_SG se genera la siguiente advertencia: DMA-API: mmci-pl18x 48220000.mmc: seguimiento de línea de caché EEXIST, asignaciones superpuestas no son compatibles ADVERTENCIA: CPU: 1 PID: 51 en kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Módulos vinculados en: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 # 1 Nombre del hardware: STMicroelectronics STM32MP257F-EV1 Placa de evaluación (DT) Cola de trabajo: events_freezable mmc_rescan Rastreo de llamadas: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x1 0/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x 14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card +0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 La depuración de la API de DMA saca a la luz asignaciones de dma con fugas, ya que dma_map_sg y dma_unmap_sg no están correctamente equilibrados. Si se produce un error en la función mmci_cmd_irq, solo se llama a la función mmci_dma_error y como esta API no se administra en la variante stm32, nunca se llama a dma_unmap_sg en esta ruta de error. • https://git.kernel.org/stable/c/46b723dd867d599420fb640c0eaf2a866ef721d4 https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53 https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4 https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85 https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be https://lists.debian.org/debian-lts-announce/2024/06/ •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix iopt_access_list_id overwrite bug Syzkaller reported the following WARN_ON: WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360 Call Trace: iommufd_access_change_ioas+0x2fe/0x4e0 iommufd_access_destroy_object+0x50/0xb0 iommufd_object_remove+0x2a3/0x490 iommufd_object_destroy_user iommufd_access_destroy+0x71/0xb0 iommufd_test_staccess_release+0x89/0xd0 __fput+0x272/0xb50 __fput_sync+0x4b/0x60 __do_sys_close __se_sys_close __x64_sys_close+0x8b/0x110 do_syscall_x64 The mismatch between the access pointer in the list and the passed-in pointer is resulting from an overwrite of access->iopt_access_list_id, in iopt_add_access(). Called from iommufd_access_change_ioas() when xa_alloc() succeeds but iopt_calculate_iova_alignment() fails. Add a new_id in iopt_add_access() and only update iopt_access_list_id when returning successfully. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommufd: corrige el error de sobrescritura de iopt_access_list_id Syzkaller informó lo siguiente WARN_ON: ADVERTENCIA: CPU: 1 PID: 4738 en drivers/iommu/iommufd/io_pagetable.c:1360 Seguimiento de llamadas: iommufd_access_change_ioas+0x2fe /0x4e0 iommufd_access_destroy_object+0x50/0xb0 iommufd_object_remove+0x2a3/0x490 iommufd_object_destroy_user iommufd_access_destroy+0x71/0xb0 iommufd_test_staccess_release+0x89/0xd0 __fput+0x272/0x b50 __fput_sync+0x4b/0x60 __do_sys_close __se_sys_close __x64_sys_close+0x8b/0x110 do_syscall_x64 La falta de coincidencia entre el puntero de acceso en la lista y el puntero pasado resulta de una sobrescritura de acceso->iopt_access_list_id, en iopt_add_access(). Llamado desde iommufd_access_change_ioas() cuando xa_alloc() tiene éxito pero iopt_calculate_iova_alignment() falla. Agregue un new_id en iopt_add_access() y actualice solo iopt_access_list_id cuando regrese exitosamente. • https://git.kernel.org/stable/c/9227da7816dd1a42e20d41e2244cb63c205477ca https://git.kernel.org/stable/c/f1fb745ee0a6fe43f1d84ec369c7e6af2310fda9 https://git.kernel.org/stable/c/9526a46cc0c378d381560279bea9aa34c84298a0 https://git.kernel.org/stable/c/aeb004c0cd6958e910123a1607634401009c9539 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix protection fault in iommufd_test_syz_conv_iova Syzkaller reported the following bug: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lock_acquire lock_acquire+0x1ce/0x4f0 down_read+0x93/0x4a0 iommufd_test_syz_conv_iova+0x56/0x1f0 iommufd_test_access_rw.isra.0+0x2ec/0x390 iommufd_test+0x1058/0x1e30 iommufd_fops_ioctl+0x381/0x510 vfs_ioctl __do_sys_ioctl __se_sys_ioctl __x64_sys_ioctl+0x170/0x1e0 do_syscall_x64 do_syscall_64+0x71/0x140 This is because the new iommufd_access_change_ioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context. Fix this by doing the same access->ioas sanity as iommufd_access_rw() and iommufd_access_pin_pages() functions do. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommufd: Se corrigió falla de protección en iommufd_test_syz_conv_iova Syzkaller informó el siguiente error: falla de protección general, probablemente para dirección no canónica 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr- deref en el rango [0x00000000000001c0-0x00000000000001c7] Seguimiento de llamadas: lock_acquire lock_acquire+0x1ce/0x4f0 down_read+0x93/0x4a0 iommufd_test_syz_conv_iova+0x56/0x1f0 iommufd_test_access_rw.isra. 0+0x2ec/0x390 iommufd_test+0x1058/0x1e30 iommufd_fops_ioctl+0x381/0x510 vfs_ioctl __do_sys_ioctl __se_sys_ioctl __x64_sys_ioctl +0x170/0x1e0 do_syscall_x64 do_syscall_64+0x71/0x140 Esto se debe a que el nuevo iommufd_access_change_ioas() establece access->ioas en NULL durante su proceso, por lo que el bloqueo podría desaparecer en un contexto de ejecución concurrente. Solucione este problema haciendo el mismo acceso->ioas cordura que hacen las funciones iommufd_access_rw() y iommufd_access_pin_pages(). • https://git.kernel.org/stable/c/9227da7816dd1a42e20d41e2244cb63c205477ca https://git.kernel.org/stable/c/fd4d5cd7a2e8f08357c9bfc0905957cffe8ce568 https://git.kernel.org/stable/c/fc719ecbca45c9c046640d72baddba3d83e0bc0b https://git.kernel.org/stable/c/cf7c2789822db8b5efa34f5ebcf1621bc0008d48 •