CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50100 – USB: gadget: dummy-hcd: Fix "task hung" problem
https://notcve.org/view.php?id=CVE-2024-50100
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix "task hung" problem The syzbot fuzzer has been encountering "task hung" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. • https://git.kernel.org/stable/c/a7f3813e589fd8e2834720829a47b5eb914a9afe https://git.kernel.org/stable/c/f828205ee3e4ddc712a13fba6c9902d51e91ddaf https://git.kernel.org/stable/c/5189df7b8088268012882c220d6aca4e64981348 https://git.kernel.org/stable/c/cf7ee2291da551fc4b109fda1f6a332cb8212065 https://git.kernel.org/stable/c/7d85884576a3be3616c260fc1fa862a59579d1ab •
CVSS: -EPSS: 0%CPEs: 8EXPL: 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/cc86f2e9876c8b5300238cec6bf0bd8c842078ee https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9 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/20cde998315a3d2df08e26079a3ea7501 •
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: 3EXPL: 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/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: 7EXPL: 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/fd9bb7e996bab9b9049fffe3f3d3b50dee191d27 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/835745a377a4519decd1a36d6b926e369 •