Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write<br /> <br /> A KASAN null-ptr-deref was observed in vcs_notifier():<br /> <br /> BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130<br /> Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {}<br /> <br /> The issue is a race condition in vcs_write(). When the console_lock is<br /> temporarily dropped (to copy data from userspace), the vc_data pointer<br /> obtained from vcs_vc() may become stale. After re-acquiring the lock,<br /> vcs_vc() is called again to re-validate the pointer. If the vc has been<br /> deallocated in the meantime, vcs_vc() returns NULL, and the while loop<br /> breaks (with written &gt; 0). However, after the loop, vcs_scr_updated(vc)<br /> is still called with the now-NULL vc pointer, leading to a null pointer<br /> dereference in the notifier chain (vcs_notifier dereferences param-&gt;vc).<br /> <br /> Fix this by adding a NULL check for vc before calling vcs_scr_updated().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: reject non-VALID session in compound request branch<br /> <br /> smb2_check_user_session() takes a shortcut for any operation that is not<br /> the first in a COMPOUND request: it reuses work-&gt;sess (the session bound by<br /> the first operation) and validates only the SessionId, then returns<br /> "valid". It never re-checks work-&gt;sess-&gt;state == SMB2_SESSION_VALID, and a<br /> SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation<br /> value) skips even the id comparison. The standalone path<br /> (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does<br /> enforce the VALID state; the compound branch bypasses all of it.<br /> <br /> A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes<br /> a fresh SMB2_SESSION_IN_PROGRESS session whose sess-&gt;user is still NULL<br /> (-&gt;user is assigned later, by ntlm_authenticate()). Used as operation 1 of<br /> a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX,<br /> \\host\IPC$), the tree-connect then runs on that IN_PROGRESS session and<br /> reaches ksmbd_ipc_tree_connect_request(), which dereferences<br /> user_name(sess-&gt;user) with sess-&gt;user == NULL (transport_ipc.c:687/701/704)<br /> -&gt; remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd<br /> worker for all clients.<br /> <br /> Reject any non-first compound operation that lands on a session which is<br /> not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path<br /> enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session,<br /> but it is never carried as a non-first compound operation, so multi-leg<br /> authentication is unaffected by this check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtiofs: fix UAF on submount umount<br /> <br /> iput() called from fuse_release_end() can Oops if the super block has<br /> already been destroyed. Normally this is prevented by waiting for<br /> num_waiting to go down to zero before commencing with super block shutdown.<br /> <br /> This only works, however, for the last submount instance, as the wait<br /> counter is per connection, not per superblock.<br /> <br /> Revert to using synchronous release requests for the auto_submounts case,<br /> which is virtiofs only at this time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si<br /> <br /> syzbot reported a general protection fault in<br /> vidtv_psi_ts_psi_write_into [1].<br /> <br /> vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does<br /> not check for this before dereferencing the returned pointer to access<br /> the continuity counter. This leads to a general protection fault when<br /> accessing a near-NULL address.<br /> <br /> The root cause is that vidtv_mux_pid_ctx_init() does not check the<br /> return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs.<br /> If the allocation fails, the PID context is never created, but init<br /> returns success. The subsequent vidtv_mux_push_si() call then gets<br /> NULL from vidtv_mux_get_pid_ctx() and crashes.<br /> <br /> Fix both the root cause (add error check in vidtv_mux_pid_ctx_init<br /> for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for<br /> all vidtv_mux_get_pid_ctx() calls.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> Workqueue: events vidtv_mux_tick<br /> RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197<br /> Call Trace:<br /> <br /> vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline]<br /> vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231<br /> vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196<br /> vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rzv2h-ivc: Fix concurrent buffer list access<br /> <br /> The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a<br /> spinlock (`rzv2h_ivc::buffers.lock`). However, in<br /> `rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the<br /> `list_del()` call is executed without holding the spinlock, which makes<br /> it possible for the list to be concurrently modified<br /> <br /> Fix that by removing a buffer from the list in the lock protected section.<br /> <br /> [assign ivc-&gt;buffers.curr in critical section as reported by Barnabas]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ov8856: free control handler on error in ov8856_init_controls()<br /> <br /> The control handler wasn&amp;#39;t freed if adding controls failed, add an error<br /> exit label and convert the existing error return to use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: always recover the gpu<br /> <br /> Previously, in case there was no more work to do, recover worker<br /> wouldn&amp;#39;t trigger recovery and would instead rely on the gpu going to<br /> sleep and then resuming when more work is submitted.<br /> <br /> Recover_worker will first increment the fence of the hung ring so, if<br /> there&amp;#39;s only one job submitted to a ring and that causes an hang, it<br /> will early out.<br /> <br /> There&amp;#39;s no guarantee that the gpu will suspend and resume before more<br /> work is submitted and if the gpu is in a hung state it will stay in that<br /> state and probably trigger a timeout again.<br /> <br /> Just stop checking and always recover the gpu.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/704066/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Add upper bound check for num_of_nodes<br /> <br /> drm/amdkfd: Add upper bound check for num_of_nodes<br /> in kfd_ioctl_get_process_apertures_new.<br /> <br /> (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vce: Prevent partial address patches<br /> <br /> In the case that only one of lo/hi is valid, the patching could result<br /> in a bad address written to in FW.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: zero-initialize GART table on allocation<br /> <br /> GART TLB is flushed after unmapping but not after mapping. Since<br /> amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a<br /> single PTE is written the TLB may speculatively load other uninitialized<br /> entries from the same cacheline. Those garbage entries can appear valid,<br /> and a subsequent write to another PTE in the same cacheline may cause the<br /> GPU to use a stale garbage PTE from the TLB.<br /> <br /> Fix this by calling memset_io() to zero-initialize the GART table with<br /> gart_pte_flags immediately after allocation.<br /> <br /> Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work<br /> since SDMA needs GART to be initialized to work.<br /> <br /> (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()<br /> <br /> The mmap_prepare hook functionality includes the ability to invoke<br /> mmap_prepare() from the mmap() hook of existing &amp;#39;stacked&amp;#39; drivers, that is<br /> ones which are capable of calling the mmap hooks of other drivers/file<br /> systems (e.g. overlayfs, shm).<br /> <br /> As part of the mmap_prepare action functionality, we deal with errors by<br /> unmapping the VMA should one arise. This works in the usual mmap_prepare<br /> case, as we invoke this action at the last moment, when the VMA is<br /> established in the maple tree.<br /> <br /> However, the mmap() hook passes a not-fully-established VMA pointer to the<br /> caller (which is the motivation behind the mmap_prepare() work), which is<br /> detached.<br /> <br /> So attempting to unmap a VMA in this state will be problematic, with the<br /> most obvious symptom being a warning in vma_mark_detached(), because the<br /> VMA is already detached.<br /> <br /> It&amp;#39;s also unncessary - the mmap() handler will clean up the VMA on error.<br /> <br /> So to fix this issue, this patch propagates whether or not an mmap action<br /> is being completed via the compatibility layer or directly.<br /> <br /> If the former, then we do not attempt VMA cleanup, if the latter, then we<br /> do.<br /> <br /> This patch also updates the userland VMA tests to reflect the change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/colorop: Fix blob property reference tracking in state lifecycle<br /> <br /> The colorop state blob property handling had memory leaks during state<br /> duplication, destruction, and reset operations. The implementation<br /> failed to follow the established pattern from drm_crtc&amp;#39;s handling of<br /> DEGAMMA/GAMMA blob properties.<br /> <br /> Issues fixed:<br /> - drm_colorop_atomic_destroy_state() was freeing state memory without<br /> releasing the blob reference, causing a leak<br /> - drm_colorop_reset() was directly freeing old state with kfree()<br /> instead of properly destroying it, leaking blob references<br /> - drm_colorop_cleanup() had duplicate blob cleanup code<br /> <br /> Changes:<br /> - Add __drm_atomic_helper_colorop_destroy_state() helper to properly<br /> release blob references before freeing state memory<br /> - Update drm_colorop_atomic_destroy_state() to call the helper<br /> - Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()<br /> for proper cleanup of old state<br /> - Simplify drm_colorop_cleanup() to use the common destruction path<br /> <br /> This matches the well-tested pattern used by drm_crtc since 2016 and<br /> ensures proper reference counting throughout the state lifecycle.<br /> <br /> Co-developed by Claude Sonnet 4.5.