CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56694 – bpf: fix recursive lock when verdict program return SK_PASS
https://notcve.org/view.php?id=CVE-2024-56694
In the Linux kernel, the following vulnerability has been resolved: bpf: fix recursive lock when verdict program return SK_PASS When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock ''' This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch • https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27 https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87 https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365 https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973 https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80 https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69 https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d4 •
CVSS: -EPSS: 0%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: 0%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: 0%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: 0%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 •