CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-56702 – bpf: Mark raw_tp arguments with PTR_MAYBE_NULL
https://notcve.org/view.php?id=CVE-2024-56702
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark raw_tp arguments with PTR_MAYBE_NULL Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL. However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0]. Thus, there is a discrepancy between the reality, that raw_tp arguments can actually be NULL, and the verifier's knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel. To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for raw_tp programs only. Ensure that we don't do this when ref_obj_id > 0, as in that case this is an acquired object and doesn't need such adjustment. The reason we do mask_raw_tp_trusted_reg logic is because other will recheck in places whether the register is a trusted_reg, and then consider our register as untrusted when detecting the presence of the PTR_MAYBE_NULL flag. To allow safe dereference, we enable PROBE_MEM marking when we see loads into trusted pointers with PTR_MAYBE_NULL. While trusted raw_tp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now. It is possible that these checks also permit passing non-raw_tp args that are trusted PTR_TO_BTF_ID with null marking. • https://git.kernel.org/stable/c/3f00c52393445ed49aadc1a567aa502c6333b1a1 https://git.kernel.org/stable/c/c9b91d2d54175f781ad2c361cb2ac2c0e29b14b6 https://git.kernel.org/stable/c/3634d4a310820567fc634bf8f1ee2b91378773e8 https://git.kernel.org/stable/c/cb4158ce8ec8a5bb528cc1693356a5eb8058094d •
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 •