CVSS: -EPSS: %CPEs: 11EXPL: 0CVE-2024-56690 – crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
https://notcve.org/view.php?id=CVE-2024-56690
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case. • https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0 https://git.kernel.org/stable/c/c9c1334697301c10e6918d747ed38abfbc0c96e7 https://git.kernel.org/stable/c/e97bf4ada7dddacd184c3e196bd063b0dc71b41d https://git.kernel.org/stable/c/546c1796ad1ed0d87dab3c4b5156d75819be2316 https://git.kernel.org/stable/c/c55fc098fd9d2dca475b82d00ffbcaf97879d77e https://git.kernel.org/stable/c/372636debe852913529b1716f44addd94fff2d28 https://git.kernel.org/stable/c/8f4f68e788c3a7a696546291258bfa5fdb215523 https://git.kernel.org/stable/c/fb2d3a50a8f29a3c66682bb426144f40e •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-56689 – PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
https://notcve.org/view.php?id=CVE-2024-56689
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio' If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it. [kwilczynski: error message update per the review feedback] [bhelgaas: commit log] • https://git.kernel.org/stable/c/1bf5f25324f7f6a52c3eb566ec5f78f6a901db96 https://git.kernel.org/stable/c/242ee2b0ad9b23f47084904fce3f9f228068a1f9 https://git.kernel.org/stable/c/c8b9d6b7d62a444e0bca5b9ae28f9f2b0f52feef https://git.kernel.org/stable/c/0e6d92e3b973de78eb7015154cf1197af9fac5c9 https://git.kernel.org/stable/c/5089b3d874e9933d9842e90410d3af1520494757 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-56688 – sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
https://notcve.org/view.php?id=CVE-2024-56688
In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. • https://git.kernel.org/stable/c/7196dbb02ea05835b9ee56910ee82cb55422c7f1 https://git.kernel.org/stable/c/cc91d59d34ff6a6fee1c0b48612081a451e05e9a https://git.kernel.org/stable/c/86a1f9fa24804cd7f9d7dd3f24af84fc7f8ec02e https://git.kernel.org/stable/c/fe6cbf0b2ac3cf4e21824a44eaa336564ed5e960 https://git.kernel.org/stable/c/87a95ee34a48dfad198a2002e4966e1d63d53f2b https://git.kernel.org/stable/c/3811172e8c98ceebd12fe526ca6cb37a1263c964 https://git.kernel.org/stable/c/638a8fa5a7e641f9401346c57e236f02379a0c40 https://git.kernel.org/stable/c/66d11ca91bf5100ae2e6b5efad97e58d8 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-56687 – usb: musb: Fix hardware lockup on first Rx endpoint request
https://notcve.org/view.php?id=CVE-2024-56687
In the Linux kernel, the following vulnerability has been resolved: usb: musb: Fix hardware lockup on first Rx endpoint request There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). • https://git.kernel.org/stable/c/baebdf48c360080710f80699eea3affbb13d6c65 https://git.kernel.org/stable/c/c749500b28cae67410792096133ee7f282439c51 https://git.kernel.org/stable/c/5906ee3693674d734177df13a519a21bb03f730d https://git.kernel.org/stable/c/f05ad9755bb294328c3d0f429164ac6d4d08c548 https://git.kernel.org/stable/c/0c89445e6d475b78d37b64ae520831cd43af7db4 https://git.kernel.org/stable/c/3fc137386c4620305bbc2a216868c53f9245670a •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-56686 – ext4: fix race in buffer_head read fault injection
https://notcve.org/view.php?id=CVE-2024-56686
In the Linux kernel, the following vulnerability has been resolved: ext4: fix race in buffer_head read fault injection When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() <bh read complete> ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty <report warning> WARN_ON_ONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection. • https://git.kernel.org/stable/c/46f870d690fecc792a66730dcbbf0aa109f5f9ab https://git.kernel.org/stable/c/77035e4d27e15f87ea55929c8bb8fb1970129e2f https://git.kernel.org/stable/c/25a5acf88fed59e060405bbb48098f4a3a2c2adc https://git.kernel.org/stable/c/61832ee7fa2fbd569d129379e795038abfb0d128 https://git.kernel.org/stable/c/2f3d93e210b9c2866c8b3662adae427d5bf511ec •