Vulnerabilities

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 /> drm/amdkfd: Fix NULL Pointer Dereference in KFD queue<br /> <br /> Through KFD IOCTL Fuzzing we encountered a NULL pointer derefrence<br /> when calling kfd_queue_acquire_buffers.<br /> <br /> (cherry picked from commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530)

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 /> 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 /> rapidio: fix an API misues when rio_add_net() fails<br /> <br /> rio_add_net() calls device_register() and fails when device_register()<br /> fails. Thus, put_device() should be used rather than kfree(). Add<br /> "mport-&gt;net = NULL;" to avoid a use after free issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm: pgtable: fix NULL pointer dereference issue<br /> <br /> When update_mmu_cache_range() is called by update_mmu_cache(), the vmf<br /> parameter is NULL, which will cause a NULL pointer dereference issue in<br /> adjust_pte():<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000030 when read<br /> Hardware name: Atmel AT91SAM9<br /> PC is at update_mmu_cache_range+0x1e0/0x278<br /> LR is at pte_offset_map_rw_nolock+0x18/0x2c<br /> Call trace:<br /> update_mmu_cache_range from remove_migration_pte+0x29c/0x2ec<br /> remove_migration_pte from rmap_walk_file+0xcc/0x130<br /> rmap_walk_file from remove_migration_ptes+0x90/0xa4<br /> remove_migration_ptes from migrate_pages_batch+0x6d4/0x858<br /> migrate_pages_batch from migrate_pages+0x188/0x488<br /> migrate_pages from compact_zone+0x56c/0x954<br /> compact_zone from compact_node+0x90/0xf0<br /> compact_node from kcompactd+0x1d4/0x204<br /> kcompactd from kthread+0x120/0x12c<br /> kthread from ret_from_fork+0x14/0x38<br /> Exception stack(0xc0d8bfb0 to 0xc0d8bff8)<br /> <br /> To fix it, do not rely on whether &amp;#39;ptl&amp;#39; is equal to decide whether to hold<br /> the pte lock, but decide it by whether CONFIG_SPLIT_PTE_PTLOCKS is<br /> enabled. In addition, if two vmas map to the same PTE page, there is no<br /> need to hold the pte lock again, otherwise a deadlock will occur. Just<br /> add the need_lock parameter to let adjust_pte() know this information.

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 /> 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 /> 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 /> 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.