CVSS: -EPSS: %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: %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: %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: 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: %CPEs: 6EXPL: 0CVE-2024-56693 – brd: defer automatic disk creation until module initialization succeeds
https://notcve.org/view.php?id=CVE-2024-56693
In the Linux kernel, the following vulnerability has been resolved: brd: defer automatic disk creation until module initialization succeeds My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list. • https://git.kernel.org/stable/c/7f9b348cb5e94259acdcbafbcaed55d3bb515304 https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56 https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152 https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842 •