Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change<br /> <br /> When disabling wifi mt7921_ipv6_addr_change() is called as a notifier.<br /> At this point mvif-&gt;phy is already NULL so we cannot use it here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: ipheth: do not stop RX on failing RX callback<br /> <br /> RX callbacks can fail for multiple reasons:<br /> <br /> * Payload too short<br /> * Payload formatted incorrecly (e.g. bad NCM framing)<br /> * Lack of memory<br /> <br /> None of these should cause the driver to seize up.<br /> <br /> Make such failures non-critical and continue processing further<br /> incoming URBs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: soc-acpi-intel-mtl-match: add missing empty item<br /> <br /> There is no links_num in struct snd_soc_acpi_mach {}, and we test<br /> !link-&gt;num_adr as a condition to end the loop in hda_sdw_machine_select().<br /> So an empty item in struct snd_soc_acpi_link_adr array is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item<br /> <br /> There is no links_num in struct snd_soc_acpi_mach {}, and we test<br /> !link-&gt;num_adr as a condition to end the loop in hda_sdw_machine_select().<br /> So an empty item in struct snd_soc_acpi_link_adr array is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/hyperv: fix kexec crash due to VP assist page corruption<br /> <br /> commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when<br /> CPUs go online/offline") introduces a new cpuhp state for hyperv<br /> initialization.<br /> <br /> cpuhp_setup_state() returns the state number if state is<br /> CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.<br /> For the hyperv case, since a new cpuhp state was introduced it would<br /> return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call<br /> is conditioned upon "hyperv_init_cpuhp &gt; 0". This will never be true and<br /> so hv_cpu_die() won&amp;#39;t be called on all CPUs. This means the VP assist page<br /> won&amp;#39;t be reset. When the kexec kernel tries to setup the VP assist page<br /> again, the hypervisor corrupts the memory region of the old VP assist page<br /> causing a panic in case the kexec kernel is using that memory elsewhere.<br /> This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec<br /> panic/hang issues").<br /> <br /> Get rid of hyperv_init_cpuhp entirely since we are no longer using a<br /> dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with<br /> cpuhp_remove_state().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/client: add missing bo locking in show_meminfo()<br /> <br /> bo_meminfo() wants to inspect bo state like tt and the ttm resource,<br /> however this state can change at any point leading to stuff like NPD and<br /> UAF, if the bo lock is not held. Grab the bo lock when calling<br /> bo_meminfo(), ensuring we drop any spinlocks first. In the case of<br /> object_idr we now also need to hold a ref.<br /> <br /> v2 (MattB)<br /> - Also add xe_bo_assert_held()<br /> <br /> (cherry picked from commit 4f63d712fa104c3ebefcb289d1e733e86d8698c7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/client: fix deadlock in show_meminfo()<br /> <br /> There is a real deadlock as well as sleeping in atomic() bug in here, if<br /> the bo put happens to be the last ref, since bo destruction wants to<br /> grab the same spinlock and sleeping locks. Fix that by dropping the ref<br /> using xe_bo_put_deferred(), and moving the final commit outside of the<br /> lock. Dropping the lock around the put is tricky since the bo can go<br /> out of scope and delete itself from the list, making it difficult to<br /> navigate to the next list entry.<br /> <br /> (cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dpaa: Pad packets to ETH_ZLEN<br /> <br /> When sending packets under 60 bytes, up to three bytes of the buffer<br /> following the data may be leaked. Avoid this by extending all packets to<br /> ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be<br /> reproduced by running<br /> <br /> $ ping -s 11 destination

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_socket: fix sk refcount leaks<br /> <br /> We must put &amp;#39;sk&amp;#39; reference before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix bridge mode operations when there are no VFs<br /> <br /> Currently, trying to set the bridge mode attribute when numvfs=0 leads to a<br /> crash:<br /> <br /> bridge link set dev eth2 hwmode vepa<br /> <br /> [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030<br /> [...]<br /> [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]<br /> [...]<br /> [ 168.976037] Call Trace:<br /> [ 168.976188] <br /> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]<br /> [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]<br /> [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0<br /> [ 168.979714] rtnetlink_rcv_msg+0x159/0x400<br /> [ 168.980451] netlink_rcv_skb+0x54/0x100<br /> [ 168.980675] netlink_unicast+0x241/0x360<br /> [ 168.980918] netlink_sendmsg+0x1f6/0x430<br /> [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0<br /> [ 168.982155] ___sys_sendmsg+0x88/0xd0<br /> [ 168.985036] __sys_sendmsg+0x59/0xa0<br /> [ 168.985477] do_syscall_64+0x79/0x150<br /> [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 168.987773] RIP: 0033:0x7f8f7950f917<br /> <br /> (esw-&gt;fdb_table.legacy.vepa_fdb is null)<br /> <br /> The bridge mode is only relevant when there are multiple functions per<br /> port. Therefore, prevent setting and getting this setting when there are no<br /> VFs.<br /> <br /> Note that after this change, there are no settings to change on the PF<br /> interface using `bridge link` when there are no VFs, so the interface no<br /> longer appears in the `bridge link` output.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: Fix uaf in __timer_delete_sync<br /> <br /> There are two paths to access mptcp_pm_del_add_timer, result in a race<br /> condition:<br /> <br /> CPU1 CPU2<br /> ==== ====<br /> net_rx_action<br /> napi_poll netlink_sendmsg<br /> __napi_poll netlink_unicast<br /> process_backlog netlink_unicast_kernel<br /> __netif_receive_skb genl_rcv<br /> __netif_receive_skb_one_core netlink_rcv_skb<br /> NF_HOOK genl_rcv_msg<br /> ip_local_deliver_finish genl_family_rcv_msg<br /> ip_protocol_deliver_rcu genl_family_rcv_msg_doit<br /> tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit<br /> tcp_v4_do_rcv mptcp_nl_remove_addrs_list<br /> tcp_rcv_established mptcp_pm_remove_addrs_and_subflows<br /> tcp_data_queue remove_anno_list_by_saddr<br /> mptcp_incoming_options mptcp_pm_del_add_timer<br /> mptcp_pm_del_add_timer kfree(entry)<br /> <br /> In remove_anno_list_by_saddr(running on CPU2), after leaving the critical<br /> zone protected by "pm.lock", the entry will be released, which leads to the<br /> occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).<br /> <br /> Keeping a reference to add_timer inside the lock, and calling<br /> sk_stop_timer_sync() with this reference, instead of "entry-&gt;add_timer".<br /> <br /> Move list_del(&amp;entry-&gt;list) to mptcp_pm_del_add_timer and inside the pm lock,<br /> do not directly access any members of the entry outside the pm lock, which<br /> can avoid similar "entry-&gt;x" uaf.