CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-56692 – f2fs: fix to do sanity check on node blkaddr in truncate_node()
https://notcve.org/view.php?id=CVE-2024-56692
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncate_node() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node(). • https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d https://git.kernel.org/stable/c/c1077078ce4589b5e5387f6b0aaa0d4534b9eb57 https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788 https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-56691 – mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
https://notcve.org/view.php?id=CVE-2024-56691
In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. • https://git.kernel.org/stable/c/9c6235c8633210cc2da0882e2e9d6ff90aa37503 https://git.kernel.org/stable/c/0997e77c51330c2866a4f39480e762cca92ad953 https://git.kernel.org/stable/c/0b648968bfa4f5c9c4983bca9f2de17626ed6fb6 https://git.kernel.org/stable/c/23230ac3c5ca3f154b64849d1cf50583b4e6b98c https://git.kernel.org/stable/c/c310e6916c0b297011d0fec03f168a6b24e9e984 https://git.kernel.org/stable/c/e1ef62e8d262e3f27446d26742208c1c81e9ee18 https://git.kernel.org/stable/c/518e414d24e7037d6cc7198e942bf47fe6f5e8e1 https://git.kernel.org/stable/c/87a07a5b0b296e489c606ca95ffc16c18 •
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: 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 •