CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52921 – drm/amdgpu: fix possible UAF in amdgpu_cs_pass1()
https://notcve.org/view.php?id=CVE-2023-52921
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix possible UAF in amdgpu_cs_pass1() Since the gang_size check is outside of chunk parsing loop, we need to reset i before we free the chunk data. Suggested by Ye Zhang (@VAR10CK) of Baidu Security. • https://git.kernel.org/stable/c/9a2393af1f35d1975204fc00035c64a1c792b278 https://git.kernel.org/stable/c/e08e9dd09809b16f8f8cee8c466841b33d24ed96 https://git.kernel.org/stable/c/90e065677e0362a777b9db97ea21d43a39211399 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50263 – fork: only invoke khugepaged, ksm hooks if no error
https://notcve.org/view.php?id=CVE-2024-50263
In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 ("mm: khugepaged: make khugepaged_enter() void function") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation. • https://git.kernel.org/stable/c/d2406291483775ecddaee929231a39c70c08fda2 https://git.kernel.org/stable/c/3b85aa0da8cd01173b9afd1f70080fbb9576c4b0 https://git.kernel.org/stable/c/985da552a98e27096444508ce5d853244019111f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50262 – bpf: Fix out-of-bounds write in trie_get_next_key()
https://notcve.org/view.php?id=CVE-2024-50262
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8. • https://git.kernel.org/stable/c/b471f2f1de8b816f1e799b80aa92588f3566e4bd https://git.kernel.org/stable/c/e8494ac079814a53fbc2258d2743e720907488ed https://git.kernel.org/stable/c/91afbc0eb3c90258ae378ae3c6ead3d2371e926d https://git.kernel.org/stable/c/590976f921723d53ac199c01d5b7b73a94875e68 https://git.kernel.org/stable/c/86c8ebe02d8806dd8878d0063e8e185622ab6ea6 https://git.kernel.org/stable/c/a035df0b98df424559fd383e8e1a268f422ea2ba https://git.kernel.org/stable/c/90a6e0e1e151ef7a9282e78f54c3091de2dcc99c https://git.kernel.org/stable/c/c4b4f9a9ab82238cb158fa4fe61a8c0ae •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50261 – macsec: Fix use-after-free while sending the offloading packet
https://notcve.org/view.php?id=CVE-2024-50261
In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: <TASK> dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 </TASK> Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 • https://git.kernel.org/stable/c/0a28bfd4971fd570d1f3e4653b21415becefc92c https://git.kernel.org/stable/c/872932cf75cf859804370a265dd58118129386fa https://git.kernel.org/stable/c/9f5ae743dbe9a2458540a7d35fff0f990df025cf https://git.kernel.org/stable/c/4614640f1d5c93c22272117dc256e9940ccac8e8 https://git.kernel.org/stable/c/f1e54d11b210b53d418ff1476c6b58a2f434dfc0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50260 – sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()
https://notcve.org/view.php?id=CVE-2024-50260
In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach(): sock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); mutex_lock(&sockmap_mutex); ... sock_map_prog_link_lookup(sockmap_link->map); mutex_unlock(&sockmap_mutex); <continue> Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released. • https://git.kernel.org/stable/c/699c23f02c65cbfc3e638f14ce0d70c23a2e1f02 https://git.kernel.org/stable/c/9afe35fdda16e09d5bd3c49a68ba8c680dd678bd https://git.kernel.org/stable/c/740be3b9a6d73336f8c7d540842d0831dc7a808b •