Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix use-after-free freeing trigger private data<br /> <br /> Commit 61d445af0a7c ("tracing: Add bulk garbage collection of freeing<br /> event_trigger_data") moved the kfree() of event_trigger_data to a kthread<br /> that runs tracepoint_synchronize_unregister() before freeing. That removed<br /> the synchronization the trigger .free callbacks used to get implicitly and<br /> inline from trigger_data_free().<br /> <br /> event_hist_trigger_free(), event_hist_trigger_named_free() and<br /> event_enable_trigger_free() free their satellite data (hist_data, cmd_ops,<br /> enable_data) right after trigger_data_free() returns. With the<br /> synchronization now deferred to the kthread, a concurrent tracepoint<br /> handler can still reach that data through the list_del_rcu()&amp;#39;d trigger,<br /> causing a use-after-free.<br /> <br /> The histogram teardown must stay synchronous: remove_hist_vars() and<br /> unregister_field_var_hists() have to detach a synthetic event from the<br /> histogram before the trigger-removal write returns, otherwise a following<br /> command races in and the synthetic-event removal fails with -EBUSY, as the<br /> trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait<br /> with the correct barrier - tracepoint_synchronize_unregister(), matching<br /> the free kthread - before freeing.<br /> <br /> The enable trigger has no such synchronous requirement, and a blocking<br /> synchronize there would re-serialize the path that commit deliberately<br /> deferred. Give it an optional private_data_free() callback that the free<br /> kthread runs after its grace period, and free enable_data from there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()<br /> <br /> tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which<br /> drops and reacquires the socket lock. Its error path tries to decide<br /> whether msg_tx names the local temporary message by comparing it with<br /> the current value of psock-&gt;cork.<br /> <br /> This comparison is unsafe when two threads send on the same socket:<br /> <br /> Thread A Thread B<br /> msg_tx = psock-&gt;cork<br /> sk_msg_alloc() fails<br /> sk_stream_wait_memory()<br /> releases the socket lock acquires the socket lock<br /> completes the cork<br /> psock-&gt;cork = NULL<br /> frees the cork<br /> reacquires the socket lock<br /> msg_tx != psock-&gt;cork<br /> sk_msg_free(msg_tx)<br /> <br /> The stale cork is therefore mistaken for the local temporary message<br /> and freed again. KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50<br /> Read of size 4 at addr ffff88810c908800 by task poc/90<br /> Call Trace:<br /> sk_msg_free+0x49/0x50<br /> tcp_bpf_sendmsg+0x14f5/0x1cc0<br /> __sys_sendto+0x32c/0x3a0<br /> __x64_sys_sendto+0xdb/0x1b0<br /> Allocated by task 89:<br /> __kasan_kmalloc+0x8f/0xa0<br /> tcp_bpf_sendmsg+0x16b3/0x1cc0<br /> Freed by task 91:<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x131/0x3c0<br /> tcp_bpf_sendmsg+0xec3/0x1cc0<br /> <br /> msg_tx can only name the stack-local tmp or the shared cork. Check for<br /> tmp directly so a changed psock-&gt;cork cannot turn a shared message into<br /> an apparent local one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Fix memory leak in bpf_jit_free()<br /> <br /> When bpf_int_jit_compile() is called for subprograms, it returns early<br /> during the first pass (!prog-&gt;is_func || extra_pass is false), keeping<br /> ctx-&gt;offset alive for the subsequent extra pass.<br /> <br /> If JIT compilation fails for a later subprogram, the BPF core aborts and<br /> calls bpf_jit_free() to clean up the first subprogram. However,<br /> bpf_jit_free() fails to free jit_data-&gt;ctx.offset, which causes a memory<br /> leak of the JIT context offsets array.<br /> <br /> So fix this by adding the missing kvfree(jit_data-&gt;ctx.offset) in<br /> bpf_jit_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drop_monitor: perform u64_stats updates under IRQ-disabled section<br /> <br /> In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(),<br /> u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were<br /> called after spin_unlock_irqrestore(&amp;...drop_queue.lock, flags), when local<br /> IRQs had already been re-enabled.<br /> <br /> Tracepoint probes can execute in IRQ or softirq context. On 32-bit<br /> architectures, u64_stats_update_begin() disables preemption but not interrupts,<br /> relying on seqcount writes. If a nested interrupt occurs on the same CPU during<br /> the 64-bit stats update, the reentrant seqcount update can corrupt the<br /> seqcount state or stats value.<br /> <br /> Fix this by performing the 64-bit per-CPU stats update before releasing<br /> drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain<br /> disabled during the u64_stats update.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix reversed error cleanup order in ucopy functions<br /> <br /> nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error<br /> cleanup labels in allocation order rather than reverse allocation order.<br /> On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or<br /> err_free_pushs) frees the first allocation and then falls through to<br /> err_free_ins, which calls u_free() on args-&gt;in_sync.s.<br /> <br /> Since args-&gt;in_sync.s still holds the ERR_PTR returned by the failed<br /> u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(),<br /> kvfree() proceeds to dereference it, which can result in a kernel oops.<br /> A failure for out_sync.s instead jumps to err_free_ins and skips freeing<br /> the first allocation, leading to a memory leak.<br /> <br /> Fix by swapping the cleanup label order so resources are freed in the<br /> correct reverse allocation sequence.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1<br /> <br /> Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in<br /> amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and<br /> BO_HANDLES chunk types.<br /> <br /> The CP_GFX_SHADOW case previously shared a bare break with the dependency<br /> and syncobj chunk types, which do not dereference a fixed-size struct. When<br /> userspace submits this chunk with length_dw == 0, vmemdup_array_user() is<br /> called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR()<br /> check. amdgpu_cs_p2_shadow() then dereferences chunk-&gt;kdata as a struct<br /> drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow-&gt;flags), faulting on the<br /> ZERO_SIZE_PTR and causing a NULL-pointer dereference.<br /> <br /> This is reachable by an unprivileged process in the render group. Reject<br /> undersized chunks with -EINVAL during pass1 so the bad submission is<br /> rejected before pass2 ever dereferences the data.<br /> <br /> (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix context pstate override handling<br /> <br /> There are several problems in the context pstate handling code.<br /> <br /> The most serious ones are potential use-after-free and NULL pointer<br /> dereferences at context initialization time. Both are due<br /> amdgpu_ctx_init() not holding the adev-&gt;pm.stable_pstate_ctx_lock, which<br /> is otherwise used from both sysfs and the context code itself for<br /> modifying and clearing the stored context pointer.<br /> <br /> Second issue is that context fini can trample over the pstate<br /> configuration set via sysfs. This is due the restore state<br /> (ctx-&gt;stable_pstate) being saved at context init time, and not if, or when<br /> the context actually changes the pstate. As the context exits it will<br /> therefore incorrectly restore to what was set before the sysfs override<br /> was requested.<br /> <br /> The simplest fix is to drastically simplify how the state is tracked, by<br /> clearly defining the points at which pstate ownership is taken and<br /> released, and to handle all transitions under the correct lock.<br /> <br /> Instead of at context init time, the previous state is saved only at the<br /> point the context overrides the current state, and is restored on context<br /> exit only if the context is still the owner of the current override state.<br /> <br /> (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Fix buffer overflow in steered register list allocation<br /> <br /> The size calculation for the steered register extarray uses only the<br /> geometry DSS mask (g_dss_mask) to determine the number of entries to<br /> allocate:<br /> <br /> total = bitmap_weight(gt-&gt;fuse_topo.g_dss_mask, ...) * steer_reg_num;<br /> <br /> However, the filling loop uses for_each_dss_steering(), which iterates<br /> over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask<br /> (geometry + compute DSS). On platforms with compute-only DSS bits, the<br /> loop writes past the allocated buffer, corrupting adjacent slab objects.<br /> <br /> This manifests as list_del corruption and SLUB redzone overwrites during<br /> drm_managed_release on device unbind, since the overflow corrupts the<br /> drmres list_head of neighboring allocations.<br /> <br /> Fix by computing the allocation size using the union of both DSS masks,<br /> matching the iteration pattern of for_each_dss_steering().<br /> <br /> --<br /> v2:<br /> - use bitmap_weighted_or() (Zhanjun)<br /> <br /> (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO<br /> <br /> The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks<br /> up the bo_va for the buffer object in the caller&amp;#39;s VM via<br /> amdgpu_vm_bo_find(), but uses the returned pointer without checking it.<br /> <br /> amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM,<br /> which is the normal case for a BO that has never been mapped. The result<br /> is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which<br /> expands to list_for_each_entry(mapping, &amp;(bo_va)-&gt;valids, list) and<br /> dereferences bo_va, causing a NULL pointer dereference.<br /> <br /> This is reachable by any process able to issue the ioctl (render group)<br /> simply by requesting mapping info for an unmapped BO.<br /> <br /> Return -ENOENT when no bo_va is found, jumping to out_exec so the<br /> drm_exec context and GEM object reference are released.<br /> <br /> (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx: fix cleaner shader IB buffer overflow<br /> <br /> The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but<br /> incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is<br /> 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a<br /> kernel page fault.<br /> <br /> The IB only needs to be a minimal NOP shell to schedule the job; the<br /> cleaner shader itself is emitted on the ring via emit_cleaner_shader().<br /> Fill 16 dwords to match the allocation.<br /> <br /> v2: Use ib_size_dw variable (Lijo)<br /> <br /> (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers<br /> <br /> Three sideband reply parsers read 16-bit fields as:<br /> <br /> val = (raw-&gt;msg[idx] curlen,<br /> raw-&gt;msg[idx+1] reads one byte past the received message data into<br /> the following struct fields (curchunk_len, curchunk_idx, curlen).<br /> <br /> Affected functions:<br /> - drm_dp_sideband_parse_enum_path_resources_ack()<br /> full_payload_bw_number and avail_payload_bw_number fields<br /> - drm_dp_sideband_parse_allocate_payload_ack()<br /> allocated_pbn field<br /> - drm_dp_sideband_parse_query_payload_ack()<br /> allocated_pbn field<br /> <br /> Fix by using a single combined check (idx + 2 &gt; curlen) before each<br /> 2-byte read. Since the check is strictly tighter than idx &gt; curlen,<br /> no separate step is needed.<br /> <br /> [added fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp/mst: fix buffer overflows in sideband chunk accumulation<br /> <br /> drm_dp_sideband_append_payload() has three related bugs when processing<br /> device-provided sideband reply data:<br /> <br /> 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken<br /> directly from the DP sideband header. If a device sends msg_len=0,<br /> curchunk_len is set to zero. The condition (curchunk_idx &gt;= curchunk_len)<br /> is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow).<br /> drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy()<br /> writes 255 bytes into msg[], both far out of bounds.<br /> <br /> 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is<br /> only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks<br /> until curchunk_idx reaches curchunk_len, writing up to 15 bytes past<br /> the end of chunk[] into msg[].<br /> <br /> 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to<br /> msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256],<br /> so the memcpy can spill into adjacent struct fields.<br /> <br /> All three are reachable from any DP MST device that can forge sideband<br /> reply messages on a physical connection.