Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Hold device ref until queue teardown completes<br /> <br /> GuC exec queue destruction can run asynchronously. If the final device<br /> put happens from a destroy worker, drmm cleanup can end up draining<br /> the same workqueue and deadlock.<br /> <br /> Hold a drm_device reference for the queue lifetime and drop it after<br /> queue teardown completes. This keeps drmm cleanup from running while<br /> async destroy work is still pending.<br /> <br /> Move GuC destroy work to a module-lifetime Xe workqueue and flush it<br /> on PCI remove so hot-unbind/rebind still waits for pending destroy work.<br /> <br /> With queue-held device refs, guc_submit_sw_fini() cannot run with live<br /> GuC IDs. Replace the fini wait with an assertion and remove the unused<br /> fini_wq.<br /> <br /> v2:<br /> - Rebase<br /> <br /> v3:<br /> - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)<br /> - Queue async teardown on system_dfl_wq instead of xe-&gt;destroy_wq. (Matt)<br /> - Drop separate deferred drm_dev_put worker.<br /> - Remove stale drain_workqueue(xe-&gt;destroy_wq) from guc_submit_sw_fini().<br /> <br /> v4:<br /> - Replace the guc_submit_sw_fini() wait with an assertion and remove<br /> the now-unused fini_wq. (sashiko)<br /> <br /> v5:<br /> - Move destroy work to a module-lifetime Xe workqueue instead of<br /> system_dfl_wq. (Matt)<br /> - Flush the module-lifetime destroy workqueue during PCI remove to<br /> preserve the old device-remove wait semantics.<br /> <br /> v6:<br /> - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid<br /> letting it outlive the xe_device/drm_device. (Sashiko)<br /> - Use WQ_MEM_RECLAIM for xe-&gt;destroy_wq because SVM pagemap destroy work<br /> can be queued from the reclaim path.<br /> <br /> v7:<br /> - Drop the per-device xe-&gt;destroy_wq and use the module-level destroy WQ<br /> for SVM pagemap destroy as well. (Matt)<br /> - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()<br /> helpers because the WQ is no longer exec-queue specific. (Matt)<br /> <br /> v8:<br /> - Rebase.<br /> <br /> v9:<br /> - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM<br /> destroy_wq because it can be queued from reclaim and embeds<br /> the dev_pagemap used by devres teardown. (Sashiko)<br /> - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM<br /> from it.<br /> - Update the module-WQ kdoc to document the GuC/SVM split.<br /> <br /> v10:<br /> - Keep xe-&gt;destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the<br /> workqueue allocation warning.<br /> <br /> v11:<br /> - Drop the SVM pagemap destroy comment as it was revision-specific.<br /> (Thomas)<br /> <br /> v12:<br /> - Rebase.<br /> <br /> (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Keep scheduler timeline name alive<br /> <br /> The scheduler keeps a pointer to the timeline name, but q-&gt;name<br /> is freed with the exec queue while scheduler fences can still<br /> reference it.<br /> <br /> Store the name in struct xe_guc_exec_queue so it shares<br /> the scheduler&amp;#39;s RCU-deferred lifetime.<br /> <br /> (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves<br /> <br /> xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO<br /> after it transitions NULL/SYSTEM -&gt; TT, and detaches them after it<br /> transitions TT -&gt; SYSTEM. Both operations were done synchronously on<br /> the CPU immediately after building the move&amp;#39;s copy/clear fence,<br /> without waiting for that fence to signal. This creates two races with<br /> VF migration:<br /> <br /> - Attach happens too late relative to the copy job it is meant to<br /> protect. If the copy job is submitted before the CCS BBs are<br /> attached, a VF migration event that pauses execution mid-copy can<br /> observe partially copied CCS metadata without the attach state<br /> needed to correctly save/restore it.<br /> <br /> - Detach happens too early relative to the copy job that moves data<br /> out of TT. The CCS BBs are torn down right after the copy fence is<br /> obtained, while the actual blit may still be in flight. A VF<br /> migration event that pauses execution mid-copy can then race the<br /> save/restore path against the still-running blit, and the CCS BBs<br /> it would need to make sense of the paused state have already been<br /> removed.<br /> <br /> Fix both races:<br /> <br /> - Move the attach call to before the copy/clear job is submitted, so<br /> the CCS BBs are already registered by the time the copy runs. On<br /> attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy()<br /> now takes the destination resource explicitly, since bo-&gt;ttm.resource<br /> is not updated to the new resource until after the move commits.<br /> <br /> - Detach only after explicitly waiting for the copy fence to signal,<br /> instead of tearing down the CCS BBs immediately after obtaining it.<br /> <br /> While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and<br /> propagate errors: the per-context loop previously never broke out on<br /> error, silently discarding earlier failures. Unwind by clearing each<br /> attached context directly via xe_migrate_ccs_rw_copy_clear() instead of<br /> reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be<br /> attached before it will clean up either one.<br /> <br /> (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/checksum: Fix csum_partial() without vector facility<br /> <br /> Currently csum_partial() calls csum_copy() with copy=false and dst=NULL.<br /> On machines without the vector facility, csum_copy() falls back to<br /> cksm(dst, ...), causing the checksum to be calculated from address zero<br /> instead of the source buffer.<br /> <br /> The VX implementation already checksums data loaded from src. Make the<br /> fallback do the same by passing src to cksm().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: raw: add locking for raw flags bitfield<br /> <br /> With commit 890e5198a6e5 ("can: raw: use bitfields to store flags in<br /> struct raw_sock") the formerly separate integer values have been integrated<br /> into a single bitfield. This led to a read-modify-write operation when<br /> changing a flag in raw_setsockopt() which now needs a locking to prevent<br /> concurrent access.<br /> <br /> Instead of adding a lock/unlock hell in each of the flag manipulations this<br /> patch introduces a wrapper for a new raw_setsockopt_locked() function<br /> analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c<br /> <br /> [mkl: use Closes tag instead of Link]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Reject unhashed UDP sockets on sockmap update<br /> <br /> UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means<br /> sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false.<br /> <br /> Because sockmap accepts unbound UDP sockets, a BPF program can increment a<br /> socket&amp;#39;s refcount via lookup. If the socket is subsequently bound, the<br /> transition from unbound to bound causes bpf_sk_release() to skip the<br /> decrement of the refcount, causing a memory leak.<br /> <br /> unreferenced object 0xffff88810bc2eb40 (size 1984):<br /> comm "test_progs", pid 2451, jiffies 4295320596<br /> hex dump (first 32 bytes):<br /> 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................<br /> 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............<br /> backtrace (crc bdee079d):<br /> kmem_cache_alloc_noprof+0x557/0x660<br /> sk_prot_alloc+0x69/0x240<br /> sk_alloc+0x30/0x460<br /> inet_create+0x2ce/0xf80<br /> __sock_create+0x25b/0x5c0<br /> __sys_socket+0x119/0x1d0<br /> __x64_sys_socket+0x72/0xd0<br /> do_syscall_64+0xa1/0x5f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Instead of special-casing for refcounted sockets, reject unhashed UDP<br /> sockets during sockmap updates, as there is no benefit to supporting those.<br /> This effectively reverts the commit under Fixes, with two exceptions:<br /> <br /> 1. sock_map_sk_state_allowed() maintains a fall-through `return true`.<br /> 2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash<br /> handler for BPF sockmap usage"), the proto::unhash BPF handler is not<br /> reintroduced.<br /> <br /> Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject<br /> unhashed sockets in bpf_sk_assign").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: core: port: Deattach Type-C connector on component unbind<br /> <br /> connector_unbind() is the mirror of connector_bind(), but it is missing<br /> the symmetric call to typec_deattach() that connector_bind() makes via:<br /> <br /> if (port_dev-&gt;child)<br /> typec_attach(port_dev-&gt;connector, &amp;port_dev-&gt;child-&gt;dev);<br /> <br /> When a Thunderbolt dock is unplugged, two teardown paths race:<br /> <br /> 1. The component framework calls connector_unbind() first, which sets<br /> port_dev-&gt;connector = NULL without calling typec_deattach(). This<br /> leaves port-&gt;usb2_dev/port-&gt;usb3_dev in struct typec_port pointing at<br /> the USB device that is about to be freed.<br /> <br /> 2. usb_disconnect() then calls typec_deattach(port_dev-&gt;connector, ...),<br /> but port_dev-&gt;connector is already NULL, so the call is a no-op and<br /> port-&gt;usb2_dev is never cleared.<br /> <br /> 3. Concurrently, UCSI detects a PD partner-disconnect event and calls<br /> typec_unregister_partner(), which reads port-&gt;usb2_dev (now a dangling<br /> pointer to freed memory) and passes it to typec_partner_unlink_device()<br /> -&gt; sysfs_remove_link() -&gt; dev_name() on the freed device, corrupting<br /> the typec/UCSI partner state.<br /> <br /> This corruption leaves the Thunderbolt tunnel in an inconsistent state on<br /> the next dock hot-plug. On affected hardware the dock&amp;#39;s I225/igc NIC fails<br /> to enumerate: AER fires a slot reset while the igc driver is still<br /> initialising ("PCIe link lost"), and the subsequent igc_reset attempt hits<br /> igc_rd32 on an already-detached device:<br /> <br /> igc 0000:2e:00.0 eth0: PCIe link lost, device now detached<br /> igc: Failed to read reg 0x0!<br /> WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005<br /> igc_rd32+0xa4/0xc0 [igc]<br /> Call Trace:<br /> igc_disable_pcie_master+0x16/0xa0 [igc]<br /> igc_reset_hw_base+0x14/0x170 [igc]<br /> igc_reset+0x63/0x110 [igc]<br /> igc_io_slot_reset+0x9e/0xd0 [igc]<br /> report_slot_reset+0x5d/0xc0<br /> pcie_do_recovery+0x209/0x400<br /> aer_isr_one_error_type+0x235/0x430<br /> aer_isr+0x4e/0x80<br /> irq_thread+0xf4/0x1f0<br /> <br /> 4. UCSI later handles the PD partner-disconnect and calls<br /> typec_unregister_partner(), which still sees the stale port-&gt;usb2_dev<br /> and tries to remove its sysfs link a second time:<br /> <br /> kernfs: can not remove &amp;#39;typec&amp;#39;, no directory<br /> WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0<br /> Workqueue: events ucsi_handle_connector_change [typec_ucsi]<br /> Call Trace:<br /> sysfs_remove_link+0x19/0x50<br /> typec_unregister_partner+0x6e/0x120 [typec]<br /> ucsi_unregister_partner+0x107/0x150 [typec_ucsi]<br /> ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi]<br /> process_one_work+0x18e/0x3e0<br /> worker_thread+0x2e3/0x420<br /> kthread+0x10a/0x230<br /> ret_from_fork+0x121/0x140<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> With worse timing the same stale pointer is dereferenced after the<br /> backing memory is freed, turning the warning into a use-after-free.<br /> <br /> Fix the asymmetry: call typec_deattach() before clearing<br /> port_dev-&gt;connector, matching what connector_bind() does on the bind side.<br /> typec_partner_deattach() is already protected by port-&gt;partner_link_lock,<br /> so it serialises safely with the concurrent typec_unregister_partner() path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Handle partially initialized auxiliary devices<br /> <br /> bnxt_aux_devices_init() calls auxiliary_device_init() before all fields<br /> used by bnxt_aux_dev_release() are initialized. After<br /> auxiliary_device_init() succeeds, later errors must unwind with<br /> auxiliary_device_uninit(), which invokes the release callback.<br /> <br /> The release callback assumes that aux_priv-&gt;id, aux_priv-&gt;edev,<br /> edev-&gt;net and edev-&gt;ulp_tbl are all populated. If allocation fails<br /> after auxiliary_device_init(), the release path can otherwise dereference<br /> or clear partially initialized state.<br /> <br /> Allocate and attach the bnxt_en_dev and ULP table before calling<br /> auxiliary_device_init(), so the release callback only sees a fully<br /> initialized auxiliary private object. If auxiliary_device_init() itself<br /> fails, free those allocations directly because device_initialize() has not<br /> run and the release callback will not be invoked.<br /> <br /> This issue was found by a static analysis checker and confirmed by manual<br /> source review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()<br /> <br /> When a dpll_pin is shared across multiple dpll_device instances and<br /> those devices are being unregistered (e.g. during driver module removal),<br /> a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().<br /> <br /> This happens under the following conditions:<br /> - A pin is registered with two or more dpll devices (dpll_A, dpll_B)<br /> - The pin has ref_sync pairs with other pins<br /> - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is<br /> unregistered first, removing it from dpll_A-&gt;pin_refs<br /> - But since the partner pin is still registered with dpll_B, its<br /> dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT<br /> run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray<br /> - When the pin itself is then unregistered from dpll_A, the delete<br /> notification calls dpll_msg_add_pin_ref_sync() which finds the<br /> partner in ref_sync_pins, passes dpll_pin_available() (partner is<br /> still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,<br /> partner) returns NULL because partner was already removed from<br /> dpll_A-&gt;pin_refs<br /> - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get<br /> callback, which dereferences it<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000034<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]<br /> Call Trace:<br /> dpll_msg_add_pin_ref_sync+0xb8/0x200<br /> dpll_cmd_pin_get_one+0x3b6/0x4b0<br /> dpll_pin_event_send+0x72/0x140<br /> __dpll_pin_unregister+0x5a/0x2b0<br /> dpll_pin_unregister+0x49/0x70<br /> <br /> Fix this by skipping ref_sync pins whose priv pointer cannot be resolved<br /> for the current dpll device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix TIME_WAIT socket reference leak on PSP policy failure<br /> <br /> Release the TIME_WAIT socket reference and jump to discard_it<br /> upon PSP policy failure in both IPv4 and IPv6 receive paths.<br /> This prevents a memory leak of tcp_tw_bucket structures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: core: sysfs: add lock to bos_descriptors_read()<br /> <br /> Add a lock to the function bos_descriptors_read().<br /> <br /> This function accesses udev-&gt;bos, which could be simultaneously freed in<br /> usb_reset_and_verify_device(), a function that is commonly called in<br /> drivers all over the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()<br /> <br /> at76_guess_freq() checks only that the received frame is at least a bare<br /> 802.11 header (24 bytes) before subtracting the fixed management-body<br /> offset:<br /> <br /> len -= el_off;<br /> <br /> For both beacon and probe response frames, el_off is 36. If the frame is<br /> shorter than el_off, subtracting it causes the calculated IE length to<br /> wrap. The length is eventually passed to cfg80211_find_elem_match() as a<br /> very large unsigned value, so the element walk runs beyond the RX skb.<br /> <br /> This path is reached from at76_rx_tasklet() while scanning. If the device<br /> delivers a truncated beacon or probe response, the oversized IE length<br /> causes an out-of-bounds read during scanning.<br /> <br /> Skip the IE lookup if the frame does not reach the variable elements,<br /> before subtracting el_off.