CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56701 – powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore
https://notcve.org/view.php?id=CVE-2024-56701
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258 • https://git.kernel.org/stable/c/06220d78f24a20549757be1014e57c382406cc92 https://git.kernel.org/stable/c/6956c0e7346ce1bbfc726755aa8da10d26e84276 https://git.kernel.org/stable/c/f6ec133668757f84e5143f1eb141fd0b83778b9e https://git.kernel.org/stable/c/fa5b5ea257135e771b489c83a2e93b5935d0108e https://git.kernel.org/stable/c/a246daa26b717e755ccc9061f47f7cd1c0b358dd https://git.kernel.org/stable/c/b125d0cf1adde7b2b47d7337fed7e9133eea3463 https://git.kernel.org/stable/c/525e18f1ba7c2b098c8ba587fb397efb34a6574c https://git.kernel.org/stable/c/cadae3a45d23aa4f6485938a67cbc47aa •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56700 – media: wl128x: Fix atomicity violation in fmc_send_cmd()
https://notcve.org/view.php?id=CVE-2024-56700
In the Linux kernel, the following vulnerability has been resolved: media: wl128x: Fix atomicity violation in fmc_send_cmd() Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. • https://git.kernel.org/stable/c/e8454ff7b9a4d56f02c095bff12d3c92ef4c7fa6 https://git.kernel.org/stable/c/d16109c9fdc1b8cea4fe63b42e06e926c3f68990 https://git.kernel.org/stable/c/3c818ad07e964bca3d27adac1e1f50e1e3c9180e https://git.kernel.org/stable/c/d7408a052aa1b4f6fb6f1c7a8877b84017a07ac9 https://git.kernel.org/stable/c/ed228b74d8a500380150965d5becabf9a1e33141 https://git.kernel.org/stable/c/372dc9509122e5d45d4c12978e31c3c7d00aaca4 https://git.kernel.org/stable/c/378ce4e08ca2b1ac7bbf1d57b68643ca4226c5f8 https://git.kernel.org/stable/c/2e63c908de357048180516b84740ed62d •
CVSS: -EPSS: 0%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: 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 •