CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2024-56698 – usb: dwc3: gadget: Fix looping of queued SG entries
https://notcve.org/view.php?id=CVE-2024-56698
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix looping of queued SG entries The dwc3_request->num_queued_sgs is decremented on completion. If a partially completed request is handled, then the dwc3_request->num_queued_sgs no longer reflects the total number of num_queued_sgs (it would be cleared). Correctly check the number of request SG entries remained to be prepare and queued. Failure to do this may cause null pointer dereference when accessing non-existent SG entry. • https://git.kernel.org/stable/c/c96e6725db9d6a04ac1bee881e3034b636d9f71c https://git.kernel.org/stable/c/8ceb21d76426bbe7072cc3e43281e70c0d664cc7 https://git.kernel.org/stable/c/0247da93bf62d33304b7bf97850ebf2a86e06d28 https://git.kernel.org/stable/c/c9e72352a10ae89a430449f7bfeb043e75c255d9 https://git.kernel.org/stable/c/1534f6f69393aac773465d80d31801b554352627 https://git.kernel.org/stable/c/b7c3d0b59213ebeedff63d128728ce0b3d7a51ec https://git.kernel.org/stable/c/70777a23a54e359cfdfafc625a57cd56434f3859 https://git.kernel.org/stable/c/b7fc65f5141c24785dc8c19249ca4efcf •
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 •