Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()<br /> <br /> Add check for the return value of mgmt_alloc_skb() in<br /> mgmt_device_connected() to prevent null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()<br /> <br /> Add check for the return value of mgmt_alloc_skb() in<br /> mgmt_remote_name() to prevent null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix &amp;#39;scheduling while atomic&amp;#39; in mptcp_pm_nl_append_new_local_addr<br /> <br /> If multiple connection requests attempt to create an implicit mptcp<br /> endpoint in parallel, more than one caller may end up in<br /> mptcp_pm_nl_append_new_local_addr because none found the address in<br /> local_addr_list during their call to mptcp_pm_nl_get_local_id. In this<br /> case, the concurrent new_local_addr calls may delete the address entry<br /> created by the previous caller. These deletes use synchronize_rcu, but<br /> this is not permitted in some of the contexts where this function may be<br /> called. During packet recv, the caller may be in a rcu read critical<br /> section and have preemption disabled.<br /> <br /> An example stack:<br /> <br /> BUG: scheduling while atomic: swapper/2/0/0x00000302<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))<br /> dump_stack (lib/dump_stack.c:124)<br /> __schedule_bug (kernel/sched/core.c:5943)<br /> schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)<br /> __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)<br /> schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)<br /> schedule_timeout (kernel/time/timer.c:2160)<br /> wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)<br /> __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)<br /> synchronize_rcu (kernel/rcu/tree.c:3609)<br /> mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)<br /> mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)<br /> mptcp_pm_get_local_id (net/mptcp/pm.c:420)<br /> subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)<br /> subflow_v4_route_req (net/mptcp/subflow.c:305)<br /> tcp_conn_request (net/ipv4/tcp_input.c:7216)<br /> subflow_v4_conn_request (net/mptcp/subflow.c:651)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)<br /> tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)<br /> tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)<br /> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))<br /> ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)<br /> ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)<br /> ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)<br /> ip_sublist_rcv (net/ipv4/ip_input.c:640)<br /> ip_list_rcv (net/ipv4/ip_input.c:675)<br /> __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)<br /> netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)<br /> napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)<br /> igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb<br /> __napi_poll (net/core/dev.c:6582)<br /> net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)<br /> handle_softirqs (kernel/softirq.c:553)<br /> __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)<br /> irq_exit_rcu (kernel/softirq.c:651)<br /> common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))<br /> <br /> <br /> This problem seems particularly prevalent if the user advertises an<br /> endpoint that has a different external vs internal address. In the case<br /> where the external address is advertised and multiple connections<br /> already exist, multiple subflow SYNs arrive in parallel which tends to<br /> trigger the race during creation of the first local_addr_list entries<br /> which have the internal address instead.<br /> <br /> Fix by skipping the replacement of an existing implicit local address if<br /> called via mptcp_pm_nl_get_local_id.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in resource_build_scaling_params<br /> <br /> Null pointer dereference issue could occur when pipe_ctx-&gt;plane_state<br /> is null. The fix adds a check to ensure &amp;#39;pipe_ctx-&gt;plane_state&amp;#39; is not<br /> null before accessing. This prevents a null pointer dereference.<br /> <br /> Found by code review.<br /> <br /> (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-steam: Fix use-after-free when detaching device<br /> <br /> When a hid-steam device is removed it must clean up the client_hdev used for<br /> intercepting hidraw access. This can lead to scheduling deferred work to<br /> reattach the input device. Though the cleanup cancels the deferred work, this<br /> was done before the client_hdev itself is cleaned up, so it gets rescheduled.<br /> This patch fixes the ordering to make sure the deferred work is properly<br /> canceled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()<br /> <br /> nvme_tcp_recv_pdu() doesn&amp;#39;t check the validity of the header length.<br /> When header digests are enabled, a target might send a packet with an<br /> invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()<br /> to access memory outside the allocated area and cause memory corruptions<br /> by overwriting it with the calculated digest.<br /> <br /> Fix this by rejecting packets with an unexpected header length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove()<br /> <br /> During the `rmmod` operation for the `intel_ishtp_hid` driver, a<br /> use-after-free issue can occur in the hid_ishtp_cl_remove() function.<br /> The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(),<br /> which can lead to accessing freed memory or resources during the<br /> removal process.<br /> <br /> Call Trace:<br /> ? ishtp_cl_send+0x168/0x220 [intel_ishtp]<br /> ? hid_output_report+0xe3/0x150 [hid]<br /> hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid]<br /> ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid]<br /> hid_hw_request+0x1f/0x40 [hid]<br /> sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub]<br /> _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger]<br /> hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger]<br /> sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub]<br /> hid_device_remove+0x49/0xb0 [hid]<br /> hid_destroy_device+0x6f/0x90 [hid]<br /> ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid]<br /> hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid]<br /> ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp]<br /> ...<br /> <br /> Additionally, ishtp_hid_remove() is a HID level power off, which should<br /> occur before the ISHTP level disconnect.<br /> <br /> This patch resolves the issue by reordering the calls in<br /> hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now<br /> called before hid_ishtp_cl_deinit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t try to talk to a dead firmware<br /> <br /> This fixes:<br /> <br /> bad state = 0<br /> WARNING: CPU: 10 PID: 702 at drivers/net/wireless/inel/iwlwifi/iwl-trans.c:178 iwl_trans_send_cmd+0xba/0xe0 [iwlwifi]<br /> Call Trace:<br /> <br /> ? __warn+0xca/0x1c0<br /> ? iwl_trans_send_cmd+0xba/0xe0 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]<br /> iwl_fw_dbg_clear_monitor_buf+0xd7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]<br /> _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea92d2c341766bcc10b18699290068a]<br /> <br /> Ask whether the firmware is alive before sending a command.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an error<br /> <br /> During the initialization of ptp, hclge_ptp_get_cycle might return an error<br /> and returned directly without unregister clock and free it. To avoid that,<br /> call hclge_ptp_destroy_clock to unregist and free clock if<br /> hclge_ptp_get_cycle failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: do not use skb_get() before dev_queue_xmit()<br /> <br /> syzbot is able to crash hosts [1], using llc and devices<br /> not supporting IFF_TX_SKB_SHARING.<br /> <br /> In this case, e1000 driver calls eth_skb_pad(), while<br /> the skb is shared.<br /> <br /> Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c<br /> <br /> Note that e1000 driver might have an issue with pktgen,<br /> because it does not clear IFF_TX_SKB_SHARING, this is an<br /> orthogonal change.<br /> <br /> We need to audit other skb_get() uses in net/llc.<br /> <br /> [1]<br /> <br /> kernel BUG at net/core/skbuff.c:2178 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178<br /> Call Trace:<br /> <br /> __skb_pad+0x18a/0x610 net/core/skbuff.c:2466<br /> __skb_put_padto include/linux/skbuff.h:3843 [inline]<br /> skb_put_padto include/linux/skbuff.h:3862 [inline]<br /> eth_skb_pad include/linux/etherdevice.h:656 [inline]<br /> e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128<br /> __netdev_start_xmit include/linux/netdevice.h:5151 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5160 [inline]<br /> xmit_one net/core/dev.c:3806 [inline]<br /> dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822<br /> sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343<br /> __dev_xmit_skb net/core/dev.c:4045 [inline]<br /> __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621<br /> dev_queue_xmit include/linux/netdevice.h:3313 [inline]<br /> llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144<br /> llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]<br /> llc_sap_next_state net/llc/llc_sap.c:182 [inline]<br /> llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209<br /> llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993<br /> sock_sendmsg_nosec net/socket.c:718 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix ownership in __udp_gso_segment<br /> <br /> In __udp_gso_segment the skb destructor is removed before segmenting the<br /> skb but the socket reference is kept as-is. This is an issue if the<br /> original skb is later orphaned as we can hit the following bug:<br /> <br /> kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan)<br /> RIP: 0010:ip_rcv_core+0x8b2/0xca0<br /> Call Trace:<br /> ip_rcv+0xab/0x6e0<br /> __netif_receive_skb_one_core+0x168/0x1b0<br /> process_backlog+0x384/0x1100<br /> __napi_poll.constprop.0+0xa1/0x370<br /> net_rx_action+0x925/0xe50<br /> <br /> The above can happen following a sequence of events when using<br /> OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an<br /> OVS_ACTION_ATTR_OUTPUT action:<br /> <br /> 1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb<br /> goes through queue_gso_packets and then __udp_gso_segment, where its<br /> destructor is removed.<br /> 2. The segments&amp;#39; data are copied and sent to userspace.<br /> 3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the<br /> same original skb is sent to its path.<br /> 4. If it later hits skb_orphan, we hit the bug.<br /> <br /> Fix this by also removing the reference to the socket in<br /> __udp_gso_segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()<br /> <br /> The system can experience a random crash a few minutes after the driver is<br /> removed. This issue occurs due to improper handling of memory freeing in<br /> the ishtp_hid_remove() function.<br /> <br /> The function currently frees the `driver_data` directly within the loop<br /> that destroys the HID devices, which can lead to accessing freed memory.<br /> Specifically, `hid_destroy_device()` uses `driver_data` when it calls<br /> `hid_ishtp_set_feature()` to power off the sensor, so freeing<br /> `driver_data` beforehand can result in accessing invalid memory.<br /> <br /> This patch resolves the issue by storing the `driver_data` in a temporary<br /> variable before calling `hid_destroy_device()`, and then freeing the<br /> `driver_data` after the device is destroyed.