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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50095 – RDMA/mad: Improve handling of timed out WRs of mad agent
https://notcve.org/view.php?id=CVE-2024-50095
In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? • https://git.kernel.org/stable/c/713adaf0ecfc49405f6e5d9e409d984f628de818 https://git.kernel.org/stable/c/7022a517bf1ca37ef5a474365bcc5eafd345a13a https://git.kernel.org/stable/c/e80eadb3604a92d2d086e956b8b2692b699d4d0a https://git.kernel.org/stable/c/a195a42dd25ca4f12489687065d00be64939409f https://git.kernel.org/stable/c/3e799fa463508abe7a738ce5d0f62a8dfd05262a https://git.kernel.org/stable/c/2a777679b8ccd09a9a65ea0716ef10365179caac •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50094 – sfc: Don't invoke xdp_do_flush() from netpoll.
https://notcve.org/view.php?id=CVE-2024-50094
In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: No invoque xdp_do_flush() desde netpoll. Yury informó de un fallo en el controlador sfc originado desde netpoll_send_udp(). • https://git.kernel.org/stable/c/401cb7dae8130fd34eb84648e02ab4c506df7d5e https://git.kernel.org/stable/c/65d4fc76d75c136744e67754d20feda609e7b793 https://git.kernel.org/stable/c/55e802468e1d38dec8e25a2fdb6078d45b647e8c •