CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50101 – iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices
https://notcve.org/view.php?id=CVE-2024-50101
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige pci_for_each_dma_alias() incorrecto para dispositivos que no sean PCI Anteriormente, la función domain_context_clear() llamaba incorrectamente a pci_for_each_dma_alias() para configurar entradas de contexto para dispositivos que no sean PCI. Esto podría provocar bloqueos del kernel u otro comportamiento inesperado. Agregue una verificación para llamar solo a pci_for_each_dma_alias() para dispositivos PCI. • https://git.kernel.org/stable/c/9807860f6ad446459d0446550cf4a2dc23bbee6c https://git.kernel.org/stable/c/59862b869275c27beb25cda2054b59a8b5d04970 https://git.kernel.org/stable/c/48f2183a4f9d3540fc5cfc8f8451621ee92c09f8 https://git.kernel.org/stable/c/9a16ab9d640274b20813d2d17475e18d3e99d834 https://git.kernel.org/stable/c/0bd9a30c22afb5da203386b811ec31429d2caa78 https://git.kernel.org/stable/c/cbfa3a83eba05240ce37839ed48280a05e8e8f6c https://git.kernel.org/stable/c/fe2e0b6cd00abea3efac66de1da22d844364c1b0 https://git.kernel.org/stable/c/04d6826ba7ba81213422276e96c90c656 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50099 – arm64: probes: Remove broken LDR (literal) uprobe support
https://notcve.org/view.php?id=CVE-2024-50099
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. • https://git.kernel.org/stable/c/9842ceae9fa8deae141533d52a6ead7666962c09 https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195 https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572 https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6 https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50098 – scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down
https://notcve.org/view.php?id=CVE-2024-50098
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Establecer SDEV_OFFLINE cuando se apaga UFS. Hay un historial de interbloqueo si se realiza el reinicio al comienzo del arranque. SDEV_QUIESCE se estableció para todos los scsi_devices de LU por el apagado de UFS, y en ese momento el controlador de audio estaba esperando a blk_mq_submit_bio() sosteniendo un mutex_lock mientras leía el binario fw. • https://git.kernel.org/stable/c/b294ff3e34490f36233230e9ca70503d3924a6f3 https://git.kernel.org/stable/c/7de759fceacff5660abf9590d11114215a9d5f3c https://git.kernel.org/stable/c/7bd9af254275fad7071d85f04616560deb598d7d https://git.kernel.org/stable/c/7774d23622416dbbbdb21bf342b3f0d92cf1dc0f https://git.kernel.org/stable/c/19a198b67767d952c8f3d0cf24eb3100522a8223 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50097 – net: fec: don't save PTP state if PTP is unsupported
https://notcve.org/view.php?id=CVE-2024-50097
In the Linux kernel, the following vulnerability has been resolved: net: fec: don't save PTP state if PTP is unsupported Some platforms (such as i.MX25 and i.MX27) do not support PTP, so on these platforms fec_ptp_init() is not called and the related members in fep are not initialized. However, fec_ptp_save_state() is called unconditionally, which causes the kernel to panic. Therefore, add a condition so that fec_ptp_save_state() is not called if PTP is not supported. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: no guardar el estado de PTP si PTP no es compatible. Algunas plataformas (como i.MX25 e i.MX27) no son compatibles con PTP, por lo que en estas plataformas no se llama a fec_ptp_init() y los miembros relacionados en fep no se inicializan. • https://git.kernel.org/stable/c/dc5fb264168c3aa8842b2db547c2b5c7df346454 https://git.kernel.org/stable/c/5763541f24d8ab2053d80fddb8479a2d0df8fd4f https://git.kernel.org/stable/c/a1477dc87dc4996dcf65a4893d4e2c3a6b593002 https://git.kernel.org/stable/c/cf53d7e76f1fb751b12ceda6a49942414d2f9ea9 https://git.kernel.org/stable/c/7745e14f4c036ce94a5eb05d06e49b0d84b306f9 https://git.kernel.org/stable/c/3192e8d4a1ef9fc9bd7a59cdce51543367e5edd6 https://git.kernel.org/stable/c/6be063071a457767ee229db13f019c2ec03bfe44 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50096 – nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error
https://notcve.org/view.php?id=CVE-2024-50096
In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: Se corrige la vulnerabilidad en migrants_to_ram tras un error de copia. La función `nouveau_dmem_copy_one` garantiza que el comando de copia push se envíe al firmware del dispositivo, pero no rastrea si se ejecutó correctamente. En el caso de un error de copia (por ejemplo, fallo del firmware o hardware), el comando de copia push se enviará a través del canal de firmware y `nouveau_dmem_copy_one` probablemente informará el éxito, lo que llevará a la función `migrate_to_ram` a devolver una página HIGH_USER sucia al usuario. • https://git.kernel.org/stable/c/5be73b690875f7eb2d2defb54ccd7f2f12074984 https://git.kernel.org/stable/c/73f75d2b5aee5a735cf64b8ab4543d5c20dbbdd9 https://git.kernel.org/stable/c/8c3de9282dde21ce3c1bf1bde3166a4510547aa9 https://git.kernel.org/stable/c/614bfb2050982d23d53d0d51c4079dba0437c883 https://git.kernel.org/stable/c/697e3ddcf1f8b68bd531fc34eead27c000bdf3e1 https://git.kernel.org/stable/c/ab4d113b6718b076046018292f821d5aa4b844f8 https://git.kernel.org/stable/c/835745a377a4519decd1a36d6b926e369b3033e2 •