CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46860 – wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change
https://notcve.org/view.php?id=CVE-2024-46860
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here. • https://git.kernel.org/stable/c/4bfee9346d8c17d928ef6da2b8bffab88fa2a553 https://git.kernel.org/stable/c/8d92bafd4c67efb692f722d73a07412b5f88c6d6 https://git.kernel.org/stable/c/479ffee68d59c599f8aed8fa2dcc8e13e7bd13c3 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46859 – platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses
https://notcve.org/view.php?id=CVE-2024-46859
In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these. • https://git.kernel.org/stable/c/e424fb8cc4e6634c10f8159b1ff5618cf7bab9c6 https://git.kernel.org/stable/c/b7c2f692307fe704be87ea80d7328782b33c3cef https://git.kernel.org/stable/c/9291fadbd2720a869b1d2fcf82305648e2e62a16 https://git.kernel.org/stable/c/6821a82616f60aa72c5909b3e252ad97fb9f7e2a https://git.kernel.org/stable/c/b38c19783286a71693c2194ed1b36665168c09c4 https://git.kernel.org/stable/c/f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4 •
CVSS: 7.0EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46858 – mptcp: pm: Fix uaf in __timer_delete_sync
https://notcve.org/view.php?id=CVE-2024-46858
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: Fix uaf in __timer_delete_sync There are two paths to access mptcp_pm_del_add_timer, result in a race condition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry) In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1). Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer". Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf. • https://git.kernel.org/stable/c/00cfd77b9063dcdf3628a7087faba60de85a9cc8 https://git.kernel.org/stable/c/0e7814b028cd50b3ff79659d23dfa9da6a1e75e1 https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707 https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076 https://access.redhat.com/security/cve/CVE-2024-46858 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46857 – net/mlx5: Fix bridge mode operations when there are no VFs
https://notcve.org/view.php?id=CVE-2024-46857
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix bridge mode operations when there are no VFs Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output. • https://git.kernel.org/stable/c/4b89251de024fb85329e4cbd8fbea551ae6c665c https://git.kernel.org/stable/c/52c4beb79e095e0631b5cac46ed48a2aefe51985 https://git.kernel.org/stable/c/65feee671e37f3b6eda0b6af28f204b5bcf7fa50 https://git.kernel.org/stable/c/505ae01f75f839b54329164bbfecf24cc1361b31 https://git.kernel.org/stable/c/b1d305abef4640af1b4f1b4774d513cd81b10cfc •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46855 – netfilter: nft_socket: fix sk refcount leaks
https://notcve.org/view.php?id=CVE-2024-46855
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning. • https://git.kernel.org/stable/c/039b1f4f24ecc8493b6bb9d70b4b78750d1b35c2 https://git.kernel.org/stable/c/6934809432d23e9e0081f82d882b8fc765deeb4a https://git.kernel.org/stable/c/f63432cd1bb224f61216e4a4726ff29ddffbed98 https://git.kernel.org/stable/c/ddc7c423c4a5386bf865474c694b48178efd311a https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896 https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715 https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11 https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c •