Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Add buffer overflow check in MS get_info_ioctl<br /> <br /> Add validation that the info size returned from the metric stream info<br /> query is not exceeded when checked against the allocated buffer size.<br /> If the firmware returns a size larger than the buffer, reject the<br /> operation with -EOVERFLOW instead of proceeding with an incorrect<br /> buffer copy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend"<br /> <br /> This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6.<br /> <br /> The idle-skip optimization bypasses GuC suspend, so the GPU may not<br /> perform the context switch that flushes TLB entries for invalidated<br /> userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB<br /> invalidation and page faults during userptr invalidation tests.<br /> <br /> Restore unconditional schedule toggling on suspend so the context-switch<br /> TLB flush is always performed.<br /> <br /> This optimization will be reintroduced with a fix that does not skip<br /> suspend in LR/preempt-fence VM mode.<br /> <br /> (cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX<br /> <br /> XN has already been extracted from its bitfield position so using<br /> FIELD_PREP() on the mask that clears XN[0] is completely broken, having<br /> the effect of unconditionally granting execute permissions...<br /> <br /> Fix the obvious mistake by manipulating the right bit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf<br /> <br /> netvsc_copy_to_send_buf() copies page buffer entries into the VMBus<br /> send buffer using phys_to_virt() on the entry PFN. Entries for the<br /> RNDIS header and the skb linear data come from kmalloc&amp;#39;d memory and<br /> are always in the kernel direct map, but entries for skb fragments<br /> reference page cache or user pages, which on 32-bit x86 with<br /> CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page<br /> phys_to_virt() returns an address outside the direct map and the<br /> subsequent memcpy() faults on the transmit softirq path, which is<br /> fatal.<br /> <br /> Map the pages with kmap_local_page() instead, handling two properties<br /> of the page buffer entries:<br /> <br /> - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity,<br /> not a native PFN. Reconstruct the physical address first and derive<br /> the native page from it, so the mapping stays correct where<br /> PAGE_SIZE &gt; HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages).<br /> <br /> - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN<br /> grouping in the page buffer array"), an entry describes a full<br /> physically contiguous fragment and pb[i].len can exceed PAGE_SIZE,<br /> while kmap_local_page() maps a single page. Copy page by page,<br /> splitting at native page boundaries.<br /> <br /> The copy path only handles packets smaller than the send section size<br /> (6144 bytes by default); larger packets take the cp_partial path where<br /> only the RNDIS header is copied. So entries here are bounded by the<br /> section size and a copy is split at most once on 4K-page systems. On<br /> !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and<br /> no mapping work is added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL<br /> <br /> A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on<br /> conn-&gt;async_requests via setup_async_work(), with cancel_fn =<br /> smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock.<br /> <br /> When the request is cancelled, the worker frees the file_lock with<br /> locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never<br /> reaches release_async_work() -- the only site that unlinks the work from<br /> conn-&gt;async_requests and clears cancel_fn/cancel_argv. The work therefore stays<br /> matchable on async_requests with a live cancel_fn pointing at the freed file_lock,<br /> until connection teardown finally runs release_async_work().<br /> <br /> smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second<br /> SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs<br /> smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in __locks_delete_block<br /> __locks_delete_block<br /> locks_delete_block<br /> ksmbd_vfs_posix_lock_unblock<br /> smb2_remove_blocked_lock<br /> smb2_cancel

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()<br /> <br /> iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock<br /> that the timer callback also acquires, leading to an ABBA deadlock on<br /> SMP systems.<br /> <br /> For the output timer (iptfs_timer):<br /> - iptfs_destroy_state() holds x-&gt;lock, calls hrtimer_cancel()<br /> - iptfs_delay_timer() callback takes x-&gt;lock<br /> <br /> For the drop timer (drop_timer):<br /> - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel()<br /> - iptfs_drop_timer() callback takes drop_lock<br /> <br /> Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq<br /> context. When hrtimer_cancel() is called for a soft timer that is<br /> currently executing on another CPU, hrtimer_cancel_wait_running() spins<br /> on softirq_expiry_lock -- the same lock held by the softirq running the<br /> callback. If the callback is blocked waiting for the spinlock held by<br /> the caller of hrtimer_cancel(), a circular dependency forms:<br /> <br /> CPU 0: holds lock_A -&gt; waits for softirq_expiry_lock<br /> CPU 1: holds softirq_expiry_lock -&gt; waits for lock_A<br /> <br /> Fix by calling hrtimer_cancel() before acquiring the respective locks.<br /> hrtimer_cancel() is safe to call without holding any lock and will wait<br /> for any in-progress callback to complete. For the output timer, the<br /> lock is still acquired afterwards to drain the packet queue. For the<br /> drop timer, the lock/unlock pair is removed entirely since it only<br /> existed to serialize with the timer callback, which hrtimer_cancel()<br /> already guarantees.<br /> <br /> Found by source code audit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe<br /> <br /> rsu_send_msg() can return -ETIMEDOUT when<br /> wait_for_completion_interruptible_timeout() fires while the SMC call is still<br /> pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION,<br /> COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE<br /> call stratix10_svc_free_channel() - which sets chan-&gt;scl to NULL - but then<br /> fall through and queue the next request on the same channel. The next svc<br /> kthread that runs will dereference pdata-&gt;chan-&gt;scl in its receive callback<br /> path, triggering a NULL pointer dereference identical to the one fixed by<br /> commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference<br /> when RSU is disabled") for the COMMAND_RSU_STATUS path.<br /> <br /> Apply the same cleanup pattern to the remaining failure paths: remove the<br /> async client, free the channel, and return early so no further messages are<br /> queued on a channel whose scl has been cleared.<br /> <br /> While at it, clean up stratix10_rsu_probe() in two ways without changing<br /> behavior:<br /> <br /> - Drop redundant zero-initialization of fields already cleared by<br /> devm_kzalloc(): client.receive_cb, status.* and spt0/1_address<br /> (INVALID_SPT_ADDRESS is 0x0).<br /> <br /> - Replace five identical 3-line error-cleanup blocks<br /> (stratix10_svc_remove_async_client() + stratix10_svc_free_channel() +<br /> return ret) with goto labels (remove_async_client, free_channel),<br /> matching the standard kernel resource-unwinding pattern and making it<br /> easier to extend the probe sequence without forgetting matching<br /> cleanup.<br /> <br /> Also move init_completion() next to mutex_init() so sync-primitive<br /> initialization is grouped before anything that could trigger a<br /> callback.<br /> <br /> ---<br /> v2: Add a minor clean-up of the function stratix10_rsu_probe() to have a<br /> centralize exit for all the rsu_send_async_msg() and rsu_send_msg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: kl5kusb105: fix bulk-out buffer overflow<br /> <br /> klsi_105_prepare_write_buffer() is called by the generic write path<br /> with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It<br /> stores a two-byte length header at the start of the buffer and copies<br /> the payload from the write fifo starting at buf + KLSI_HDR_LEN, but<br /> passes the full buffer size as the number of bytes to copy:<br /> <br /> count = kfifo_out_locked(&amp;port-&gt;write_fifo, buf + KLSI_HDR_LEN,<br /> size, &amp;port-&gt;lock);<br /> <br /> When the fifo holds at least size bytes, size bytes are copied starting<br /> two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its<br /> end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for<br /> the header as safe_serial already does.<br /> <br /> Writing bulk_out_size or more bytes to the tty triggers a slab<br /> out-of-bounds write, observed with KASAN by emulating the device with<br /> dummy_hcd and raw-gadget:<br /> <br /> BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0<br /> Write of size 64 at addr ffff888112c62202 by task python3<br /> kfifo_copy_out<br /> klsi_105_prepare_write_buffer [kl5kusb105]<br /> usb_serial_generic_write_start [usbserial]<br /> Allocated by task 139:<br /> usb_serial_probe [usbserial]<br /> The buggy address is located 2 bytes inside of allocated 64-byte region<br /> <br /> The out-of-bounds write no longer occurs with this change applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()<br /> <br /> build_i2c_fw_hdr() allocates a fixed-size buffer of<br /> (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then<br /> copies le16_to_cpu(img_header-&gt;Length) bytes into it without<br /> validating that Length fits within the available space after the<br /> firmware record header.<br /> <br /> img_header-&gt;Length is a __le16 from the firmware file and can be<br /> up to 65535. check_fw_sanity() validates the total firmware size<br /> but not img_header-&gt;Length specifically.<br /> <br /> Fix by rejecting images where img_header-&gt;Length exceeds the<br /> available destination space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Forcibly close timer instances at closing<br /> <br /> When snd_timer object is freed via snd_timer_free() and still pending<br /> snd_timer_instance objects are assigned to the timer object, it tries<br /> to unlink all instances and just set NULL to each ti-&gt;timer, then<br /> releases the resources immediately. The problem is, however, when<br /> there are slave timer instances that are associated with a master<br /> instance linked to this timer: namely, those slave instances still<br /> point to the freed timer object although the master instance is<br /> unlinked, which may lead to user-after-free. The bug can be easily<br /> triggered particularly when a new userspace-driven timers<br /> (CONFIG_SND_UTIMER) is involved, since it can create and delete the<br /> timer object via a simple file open/close, while the other<br /> applications may keep accessing to that timer.<br /> <br /> This patch is an attempt to paper over the problem above: now instead<br /> of just unlinking, call snd_timer_close[_locked]() forcibly for each<br /> pending timer instance, so that all assigned slave timer instances are<br /> properly detached, too. Since snd_timer_close() might be called later<br /> by the driver that created that instance, the check of<br /> SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Fix UAF at snd_timer_user_params()<br /> <br /> At releasing a timer object, e.g. when a userspace timer<br /> (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it<br /> tries to detach the timer instances and release the resources.<br /> However, it&amp;#39;s still possible that other in-flight tasks are holding<br /> the timer instance where the to-be-deleted timer object is associated,<br /> and this may lead to racy accesses.<br /> <br /> Fortunately, most of ioctls dealing with the timer instance list<br /> already have the protection with register_mutex, and this also avoids<br /> such races. But, SNDRV_TIMER_IOCTL_PARAMS isn&amp;#39;t protected, hence the<br /> concurrent ioctl may lead to use-after-free.<br /> <br /> This patch just adds the guard with register_mutex to protect<br /> snd_timer_user_params() for covering the code path as a quick<br /> workaround. It&amp;#39;s no hot-path but rather a rarely issued ioctl, so the<br /> performance penalty doesn&amp;#39;t matter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries<br /> <br /> When a bundle recv retries inside io_recv_finish(), the merge logic OR<br /> the saved cflags from the previous iteration with the cflags returned by<br /> the new iteration:<br /> cflags = req-&gt;cqe.flags | (cflags &amp; CQE_F_MASK);<br /> <br /> Bits listed in CQE_F_MASK are inherited from the new iteration, and all<br /> other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the<br /> saved cflags. Before this change CQE_F_MASK covered only<br /> IORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE.<br /> <br /> When using provided buffer rings (IOU_PBUF_RING_INC) with incremental<br /> mode, and bundle recv, io_kbuf_inc_commit() can leave the head ring<br /> entry partially consumed, __io_put_kbufs() then sets<br /> IORING_CQE_F_BUF_MORE on the returned cflags so userspace knows the<br /> buffer ID will be reused for subsequent completions.<br /> <br /> Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge above<br /> silently dropped it whenever the final retry iteration partially<br /> consumed the buffer, and the subsequent req-&gt;cqe.flags = cflags &amp;<br /> ~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in the<br /> carried-over cflags had one been present. Userspace would then<br /> wrongfully advance it ring head past an entry the kernel still uses.<br /> <br /> Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from the<br /> new iteration into the user-visible CQE and stripped from the saved<br /> cflags between iterations.