Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()<br /> <br /> A DIRECTORY entry&amp;#39;s value field is used as the dir_offset for a<br /> recursive call into __tb_property_parse_dir() with no depth counter.<br /> A crafted peer that chains DIRECTORY entries into a back-reference<br /> loop drives the parser until the kernel stack is exhausted and the<br /> guard page fires. Any untrusted XDomain peer (cable, dock, in-line<br /> inspector, adjacent host) that reaches the PROPERTIES_REQUEST<br /> control-plane exchange can trigger this without authentication.<br /> <br /> Thread a depth counter through tb_property_parse() and<br /> __tb_property_parse_dir(), and reject blocks that exceed<br /> TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any<br /> observed legitimate XDomain layout.<br /> <br /> Operators who do not need XDomain host-to-host discovery can disable<br /> the path entirely with thunderbolt.xdomain=0 on the kernel command<br /> line.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: property: Reject dir_len length (u16 widened to size_t). Two distinct OOB conditions<br /> follow when entry-&gt;length uuid), ...) which always reads 4 dwords from<br /> dir_offset. tb_property_entry_valid() only enforces<br /> dir_offset + entry-&gt;length length in 0..3 passes that gate but lets the UUID copy<br /> run off the block (e.g. dir_offset = 497, dir_len = 3 in a<br /> 500-dword block reads block[497..501]).<br /> <br /> 2. After the kmemdup, content_len = dir_len - 4 underflows size_t<br /> to ~SIZE_MAX, nentries becomes SIZE_MAX / 4, and the entry<br /> walk runs OOB on each iteration until an entry fails<br /> validation or the kernel oopses on an unmapped page.<br /> <br /> Reject dir_len properties) up to immediately after<br /> the dir allocation so the new error-return path (and the existing<br /> uuid-alloc failure path) calling tb_property_free_dir() sees a<br /> walkable list rather than the zero-initialized NULL next/prev that<br /> list_for_each_entry_safe() would oops on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()<br /> <br /> entry-&gt;value is u32 and entry-&gt;length is u16; the sum is performed in<br /> u32 and wraps. A malicious XDomain peer can pick<br /> value = 0xffffff00, length = 0x100 so the sum 0x100000000 wraps to 0<br /> and passes the &gt; block_len check. tb_property_parse() then passes<br /> entry-&gt;value to parse_dwdata() as a dword offset into the property<br /> block, reading attacker-directed memory far past the allocation.<br /> <br /> For TEXT-typed entries with the "deviceid" or "vendorid" keys this<br /> lands in xd-&gt;device_name / xd-&gt;vendor_name and is readable back via<br /> the per-XDomain device_name / vendor_name sysfs attributes; the leak<br /> is NUL-bounded (kstrdup() stops at the first zero byte) and<br /> untargeted (the attacker picks a delta, not an absolute address).<br /> DATA-typed entries are parsed into property-&gt;value.data but not<br /> generically surfaced to userspace.<br /> <br /> Use check_add_overflow() so a wrapped sum is rejected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: serialize DMABUF cancel against request completion<br /> <br /> ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the<br /> completed request but leaves priv-&gt;req, the back-pointer that<br /> ffs_dmabuf_transfer() set on submission, pointing at the freed<br /> memory. A later FUNCTIONFS_DMABUF_DETACH ioctl or<br /> ffs_epfile_release() on the close path still sees priv-&gt;req<br /> non-NULL under ffs-&gt;eps_lock:<br /> <br /> if (priv-&gt;ep &amp;&amp; priv-&gt;req)<br /> usb_ep_dequeue(priv-&gt;ep, priv-&gt;req);<br /> <br /> so usb_ep_dequeue() is called on a freed usb_request.<br /> <br /> On dummy_hcd the dequeue path only walks a live queue and<br /> pointer-compares, so the freed pointer reads without faulting and<br /> KASAN requires an explicit check at the FunctionFS call site to<br /> surface the use-after-free. On SG-capable in-tree UDCs the<br /> dequeue path dereferences the supplied request immediately:<br /> <br /> * chipidea&amp;#39;s ep_dequeue() does<br /> container_of(req, struct ci_hw_req, req) and reads<br /> hwreq-&gt;req.status before acquiring its own lock.<br /> * cdnsp&amp;#39;s cdnsp_gadget_ep_dequeue() reads request-&gt;status first.<br /> <br /> The narrower option of clearing priv-&gt;req via cmpxchg() in the<br /> completion does not close the race: the completion runs without<br /> eps_lock, so a cancel path holding eps_lock can still observe<br /> priv-&gt;req non-NULL, race a concurrent completion that clears and<br /> frees, and pass the freed pointer to usb_ep_dequeue(). A slightly<br /> longer fix that moves the free into the cleanup work is needed.<br /> <br /> Same class of lifetime race as the recent usbip-vudc timer fix [1].<br /> <br /> Take eps_lock in the sole place that mutates priv-&gt;req from the<br /> callback direction by moving usb_ep_free_request() out of the<br /> completion into ffs_dmabuf_cleanup(), the existing work handler<br /> scheduled by ffs_dmabuf_signal_done() on<br /> ffs-&gt;io_completion_wq. Clear priv-&gt;req there under eps_lock<br /> before freeing, and only clear if priv-&gt;req still names our<br /> request (a subsequent ffs_dmabuf_transfer() on the same<br /> attachment may have queued a new one).<br /> <br /> This keeps the existing dummy_hcd sync-dequeue invariant: the<br /> completion callback is still invoked by the UDC without<br /> eps_lock held (dummy_hcd drops its own lock before calling the<br /> callback), and the callback now takes no f_fs lock at all.<br /> Serialization against the cancel path happens in cleanup, which<br /> runs from the workqueue with no f_fs lock held on entry.<br /> <br /> The priv ref count protects the containing ffs_dmabuf_priv:<br /> ffs_dmabuf_transfer() takes a ref via ffs_dmabuf_get(), cleanup<br /> drops it via ffs_dmabuf_put(), so priv stays live for the<br /> cleanup even after the cancel path&amp;#39;s list_del + ffs_dmabuf_put.<br /> <br /> The ffs_dmabuf_transfer() error path no longer frees usb_req<br /> inline: fence-&gt;req and fence-&gt;ep are set before usb_ep_queue(),<br /> so ffs_dmabuf_cleanup() (scheduled by the error-path<br /> ffs_dmabuf_signal_done()) owns the free regardless of whether<br /> the queue succeeded.<br /> <br /> Reproduced under KASAN on both detach and close paths against<br /> dummy_hcd with an observability hook<br /> (kasan_check_byte(priv-&gt;req) immediately before usb_ep_dequeue)<br /> at the two FunctionFS cancel sites to surface the stale-pointer<br /> access; the hook is not part of this patch. The KASAN<br /> allocator / free stacks in the captured splats identify the<br /> same request: alloc in dummy_alloc_request, free in<br /> dummy_timer, fault reached from ffs_epfile_release (close) and<br /> from the FUNCTIONFS_DMABUF_DETACH ioctl (detach). With the<br /> patch applied, both paths are silent under the same hook.<br /> <br /> The bug is reached from the FunctionFS device node, which in<br /> real deployments is owned by the privileged gadget daemon<br /> (adbd, UMS, composite gadget services, etc.); it is not<br /> reachable from unprivileged userspace or from a USB host on the<br /> cable. FunctionFS mounts default to GLOBAL_ROOT_UID, but the<br /> filesystem supports uid=, gid=, and fmode= delegation to a<br /> non-root gadget daemon, so on real deployments the attacker may<br /> be a less-privileged service rather than root.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: copy only received bytes on short ep0 read<br /> <br /> ffs_ep0_read() allocates its control-OUT data buffer with<br /> kmalloc() (not kzalloc) at the Length value from the Setup<br /> packet, then copies that full len to userspace regardless of<br /> how many bytes were actually received:<br /> <br /> data = kmalloc(len, GFP_KERNEL);<br /> ...<br /> ret = __ffs_ep0_queue_wait(ffs, data, len);<br /> if ((ret &gt; 0) &amp;&amp; (copy_to_user(buf, data, len)))<br /> ret = -EFAULT;<br /> <br /> __ffs_ep0_queue_wait() returns req-&gt;actual, which on a short<br /> control OUT transfer is strictly less than len. The<br /> copy_to_user() call still copies len bytes, so on a short OUT<br /> the last (len - ret) bytes of the kmalloc() buffer --<br /> uninitialised slab residue -- are delivered to the FunctionFS<br /> daemon.<br /> <br /> Short ep0 OUT completions are specified USB control-transfer<br /> behavior and are produced by in-tree UDCs:<br /> <br /> * dwc2 continues on req-&gt;actual length for ep0 DATA OUT<br /> (short-not-ok is the only ep0-OUT stall path).<br /> * aspeed_udc ends ep0 OUT on rx_len ep.maxpacket.<br /> * renesas_usbf logs "ep0 short packet" and completes the<br /> request.<br /> * dwc3 stalls on short IN but not on short OUT.<br /> <br /> A short ep0 OUT is therefore not evidence of a broken UDC; it is<br /> a normal condition f_fs has to cope with. The sibling gadgetfs<br /> implementation in drivers/usb/gadget/legacy/inode.c already does<br /> this correctly via min(len, dev-&gt;req-&gt;actual) before<br /> copy_to_user(). This patch brings f_fs.c to the same safe<br /> pattern rather than trimming at a defensive layer.<br /> <br /> The bug is reached from the FunctionFS device node, which in<br /> real deployments is owned by the privileged gadget daemon<br /> (adbd, UMS, composite gadget services, etc.); it is not<br /> reachable from unprivileged userspace. Linux host stacks<br /> normally reject short-wLength control OUTs before they reach<br /> the gadget, so reproducing this required a build that<br /> bypasses that host-side check. With the bypass in place, a<br /> 1-byte payload on a 64-byte Setup produces 63 bytes of<br /> non-canary slab residue in the daemon&amp;#39;s read buffer.<br /> <br /> Fix by copying only ret (actually received) bytes to<br /> userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO<br /> <br /> The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl()<br /> holds three cleanup-tracked resources before calling kvcalloc():<br /> the drm_gem_object reference from drm_gem_object_lookup(), the<br /> drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and<br /> the drm_exec lock on the per-process VM root page directory via<br /> amdgpu_vm_lock_pd(). All three are released by the out_exec<br /> label that every other error path in this function jumps to.<br /> The kvcalloc() failure path returns -ENOMEM directly, skipping<br /> out_exec and leaking all three.<br /> <br /> The leaked per-process VM root PD dma_resv lock is the<br /> load-bearing leak: any subsequent operation on the same VM<br /> (further GEM ops, command-submission, eviction, TTM shrinker<br /> callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is<br /> DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local<br /> denial of service against the caller&amp;#39;s GPU context, reachable<br /> by any process with /dev/dri/renderD* access.<br /> <br /> Route the failure through out_exec so drm_exec_fini() and<br /> drm_gem_object_put() run.<br /> <br /> Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega<br /> (Lucienne): the failing ioctl returns -ENOMEM and a second<br /> GET_MAPPING_INFO on the same fd then blocks in<br /> drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the<br /> caller does not reap the task; the fd-release path during<br /> process exit goes through amdgpu_gem_object_close() -&gt;<br /> drm_exec_prepare_obj() on the same lock, leaving the task in D<br /> state until the box is rebooted. The patched kernel was not<br /> rebuilt and re-tested on this hardware; the fix is mechanical.<br /> Tested on a single Lucienne / Vega box only.<br /> <br /> Ziyi Guo posted an independent INT_MAX-bound check for<br /> args-&gt;num_entries in the same branch [1]; the two patches are<br /> complementary and can land in either order.<br /> <br /> (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger<br /> <br /> get_queue_ids() computes array_size = num_queues * sizeof(uint32_t),<br /> which could overflow on 32-bit size_t build. using array_size()<br /> instead, it saturates to SIZE_MAX on overflow.<br /> <br /> (cherry picked from commit 2d57a0475f085c08b49312dfd8edcb461845f285)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix NULL pointer bug in svm_range_set_attr<br /> <br /> The process_info could be NULL if user doesn&amp;#39;t call kfd_ioctl_acquire_vm<br /> before calling kfd_ioctl_svm.<br /> <br /> (cherry picked from commit 83a26c812e0529eb040d31a76f73e33e637243d4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ<br /> <br /> When uart_flush_buffer() runs before the DMA completion IRQ is delivered,<br /> the following race can occur (all steps serialized by uart_port_lock):<br /> <br /> 1. DMA starts: tx_remaining = N, kfifo contains N bytes<br /> 2. DMA completes in hardware; IRQ is pending but not yet delivered<br /> 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),<br /> making kfifo_len() = 0 while tx_remaining remains N<br /> 4. uart_flush_buffer() releases the port lock<br /> 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls<br /> uart_xmit_advance(uport, tx_remaining) on an empty kfifo<br /> <br /> uart_xmit_advance() increments kfifo-&gt;out by tx_remaining. Since<br /> kfifo_reset() already set both in and out to 0, out wraps past in,<br /> causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next<br /> start_tx_dma() call then submits a DMA transfer of stale buffer data.<br /> <br /> Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()<br /> and skipping uart_xmit_advance() when fifo_len

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential UAF in TTM object purge<br /> <br /> TLDR: The bo-&gt;ttm object might be changed by calling ttm_bo_validate(),<br /> move casting it to an i915_tt object later to actually get the right<br /> pointer.<br /> <br /> A user reported hitting the following bug under heavy use on DG2:<br /> <br /> [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI<br /> [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy)<br /> [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025<br /> [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915]<br /> [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78<br /> [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282<br /> [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000<br /> [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff<br /> [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000<br /> [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0<br /> [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0<br /> [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000<br /> [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0<br /> [26620.095612] PKRU: 55555554<br /> [26620.095612] Call Trace:<br /> [26620.095615] <br /> [26620.095615] i915_ttm_move+0x2b9/0x420 [i915]<br /> [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm]<br /> [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915]<br /> [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm]<br /> [26620.095669] ttm_bo_evict+0x100/0x150 [ttm]<br /> [26620.095671] ? preempt_count_add+0x64/0xa0<br /> [26620.095673] ? _raw_spin_lock+0xe/0x30<br /> [26620.095675] ? _raw_spin_unlock+0xd/0x30<br /> [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915]<br /> [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm]<br /> [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm]<br /> [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm]<br /> [26620.095709] ? init_object+0x62/0xd0<br /> [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm]<br /> [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30<br /> [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915]<br /> [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915]<br /> [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915]<br /> [26620.095786] ? alloc_debug_processing+0xd0/0x100<br /> [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30<br /> [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915]<br /> [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915]<br /> [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915]<br /> [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915]<br /> [26620.095904] eb_validate_vmas+0x170/0xa00 [i915]<br /> [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915]<br /> [26620.095953] ? alloc_debug_processing+0xd0/0x100<br /> [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30<br /> [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915]<br /> [26620.095977] ? __wake_up_sync_key+0x32/0x50<br /> [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915]<br /> [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0<br /> [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915]<br /> <br /> Results from decode_stacktrace.sh pointed to dereference of a file pointer<br /> field of a i915 TTM page vector container associated with an object being<br /> purged on eviction. That path is taken when the object is marked as no<br /> longer needed.<br /> <br /> Code analysis revealed a possibility of the i915 TTM page vector container<br /> being replaced with a new instance inside a function that purges content<br /> of the object, should it be still busy. That function is called,<br /> indirectly via a more general function that changes the object&amp;#39;s placement<br /> and caching policy,<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: fix race between change_handle and handle_delete<br /> <br /> drm_gem_change_handle_ioctl leaves the old handle live in the IDR<br /> during the window between spin_unlock(table_lock) and the final<br /> spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old<br /> handle succeeds in this window, decrements handle_count to 0, and frees<br /> the GEM object while the new handle&amp;#39;s IDR entry still references it.<br /> <br /> NULL the old handle&amp;#39;s IDR entry before dropping table_lock so that any<br /> concurrent GEM_CLOSE on the old handle sees NULL and returns -EINVAL.<br /> Restore the old entry on the prime-bookkeeping error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Validate CHAP_R length before base64 decode<br /> <br /> chap_server_compute_hash() allocates client_digest as<br /> kzalloc(chap-&gt;digest_size) and then, for BASE64-encoded responses,<br /> passes chap_r directly to chap_base64_decode() without checking whether<br /> the input length could produce more than digest_size bytes of output.<br /> <br /> chap_base64_decode() writes to the destination unconditionally as long<br /> as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and<br /> the "0b" prefix stripped by extract_param(), up to 127 base64 characters<br /> can reach the decoder. 127 characters decode to 95 bytes. For SHA-256<br /> (digest_size=32) this overflows client_digest by 63 bytes; for MD5<br /> (digest_size=16) the overflow is 79 bytes.<br /> <br /> The length check at line 344 fires after the write has already happened.<br /> <br /> The HEX branch in the same switch statement already validates the length<br /> up front. Apply the same approach to the BASE64 branch: strip trailing<br /> base64 padding characters, then reject any input whose data length<br /> exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.<br /> <br /> Stripping trailing &amp;#39;=&amp;#39; before the comparison handles both padded and<br /> unpadded encodings. chap_base64_decode() already returns early on &amp;#39;=&amp;#39;,<br /> so the full original string is still passed to the decoder unchanged.<br /> <br /> The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is<br /> kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at<br /> CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1<br /> base64 characters reach the decoder. The maximum decoded size,<br /> DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than<br /> CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is<br /> added at the call site to document this.