Page 7 of 14766 results (0.036 seconds)

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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. • 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: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83822: Fix NULL pointer dereference on DP83825 devices The probe() function is only used for DP83822 and DP83826 PHY, leaving the private data pointer uninitialized for the DP83825 models which causes a NULL pointer dereference in the recently introduced/changed functions dp8382x_config_init() and dp83822_set_wol(). Add the dp8382x_probe() function, so all PHY models will have a valid private data pointer to fix this issue and also prevent similar issues in the future. • https://git.kernel.org/stable/c/9ef9ecfa9e9f0472adf5b254bda1e0788bc8eaad https://git.kernel.org/stable/c/67b61e2f4c9c5df97a9a2ef7a1fe35eae00531f4 https://git.kernel.org/stable/c/3f62ea572b3e8e3f10c39a9cb4f04ca9ae5f2952 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. • https://git.kernel.org/stable/c/9ad1a37493338cacf04e2c93acf44d151a7adda8 https://git.kernel.org/stable/c/1f31f51bfc8214a6deaac2920e6342cb9d019133 https://git.kernel.org/stable/c/38f5db5587c0ee53546b28c50ba128253181ac83 https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00 https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad2196e90fc2 https://git.kernel.org/stable/c/cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0 •