Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix division by zero with invalid uvd dimensions<br /> <br /> When width or height is less than 16, width_in_mb or height_in_mb<br /> becomes 0, leading to fs_in_mb being 0. This causes a division by<br /> zero when calculating num_dpb_buffer in H264 and H264 Perf decode<br /> paths.<br /> <br /> Add validation to reject frames with width

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vce: fix integer overflow in image size<br /> <br /> Fix a security vulnerability where malicious VCE command streams<br /> with oversized dimensions (e.g. 65536×65536) cause 32-bit integer<br /> overflow, wrapping the calculated buffer size to 0. This bypasses<br /> validation and allows GPU firmware to perform out-of-bound memory<br /> access.<br /> <br /> The fix uses 64-bit arithmetic to detect overflow and rejects<br /> invalid dimensions before they reach the hardware.<br /> <br /> V2: remove redundant check<br /> V3: modify max height value<br /> V4: remove size64<br /> <br /> (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate ACE size against SID sub-authorities<br /> <br /> set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but<br /> does not verify that the declared ACE size contains all sub-authorities<br /> described by that field. An undersized ACE can therefore be copied<br /> and later make the POSIX ACL deduplication walk inspect data beyond<br /> the copied ACE boundary.<br /> <br /> The existing initial bound check is also too small. It only ensures<br /> that the ACE size field is accessible before set_ntacl_dacl() reads<br /> sid.num_subauth farther into the input buffer.<br /> <br /> Require enough input for the fixed SID header before accessing<br /> num_subauth, reject ACEs smaller than that header, and skip ACEs<br /> whose declared size cannot contain the complete SID. This makes the<br /> validation consistent with the other ACE walk paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: bound DACL dedup walk to copied ACEs<br /> <br /> set_ntacl_dacl() can stop copying ACEs before consuming the full input<br /> DACL when size accounting overflows.<br /> <br /> When that happens, num_aces reflects only the ACEs that were actually<br /> copied into the output DACL, but set_posix_acl_entries_dacl() still<br /> receives nt_num_aces and uses it to walk the existing ACE array during<br /> dedup.<br /> <br /> That makes the dedup walk scan past the copied ACE array and inspect<br /> buffer tail that does not contain valid ACEs.<br /> <br /> Split the two meanings currently carried by the NT ACE count. Pass the<br /> number of copied NT ACEs to bound the dedup walk, and preserve the<br /> original "input DACL had NT ACEs" state separately for the<br /> Everyone/default ACL fallback.<br /> <br /> This keeps the dedup walk aligned with the ACEs that are actually<br /> present in the rebuilt DACL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL<br /> <br /> check_add_overflow() unconditionally writes the truncated sum into *d<br /> even on overflow, per its contract in include/linux/overflow.h.<br /> The four check_add_overflow() guards in set_posix_acl_entries_dacl()<br /> and set_ntacl_dacl() break out of the ACE-building loops on overflow,<br /> but the truncated *size is then consumed downstream at the end of<br /> set_ntacl_dacl():<br /> <br /> pndacl-&gt;size = cpu_to_le16(le16_to_cpu(pndacl-&gt;size) + size);<br /> <br /> This produces an on-wire NT ACL whose pndacl-&gt;size under-reports the<br /> bytes actually written by the preceding fill_ace_for_sid()/memcpy()<br /> calls, yielding a malformed ACL that can trigger out-of-bounds reads<br /> when re-parsed by clients or ksmbd itself.<br /> <br /> Restore *size to its pre-addition value on each overflow branch (via<br /> `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break,<br /> *size once again holds the cumulative size of the successfully-written<br /> ACEs. The committed ACL is then truncated-but-self-consistent rather<br /> than malformed.<br /> <br /> The ksmbd DACL builders are the only check_add_overflow() sites found<br /> where an overflow path breaks out of a loop and the destination value<br /> is consumed afterward. The other nearby break-style cases either<br /> return -EINVAL on overflow (transport_ipc.c) or break without<br /> consuming the overflowed destination value afterward (buildid.c).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl<br /> <br /> set_ntacl_dacl() copies each ACE from the attacker-controlled stored<br /> security descriptor verbatim into the response DACL without checking<br /> sid.num_subauth. The ACE bytes (including an unchecked num_subauth)<br /> originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is<br /> stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE<br /> with `break` rather than an error, so parse_sec_desc() still returns<br /> success and the malformed SD reaches the xattr intact.<br /> <br /> On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a<br /> POSIX access ACL, build_sec_desc() -&gt; set_ntacl_dacl() -&gt;<br /> set_posix_acl_entries_dacl() walks the copied ACEs and reads<br /> <br /> ntace-&gt;sid.sub_auth[ntace-&gt;sid.num_subauth - 1]<br /> <br /> with num_subauth taken straight from the stored SD. Since sub_auth[]<br /> is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g.<br /> 255) drives an out-of-bounds heap read of ~1 KB with an offset fully<br /> controlled by an authenticated client.<br /> <br /> The sibling functions already gate this field:<br /> parse_dacl() -- num_subauth == 0 || &gt; SID_MAX_SUB_AUTHORITIES<br /> parse_sid() -- num_subauth &gt; SID_MAX_SUB_AUTHORITIES<br /> smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES)<br /> set_ntacl_dacl() is the lone inconsistent path that omits the check.<br /> <br /> Add the same num_subauth validation in set_ntacl_dacl() before copying<br /> the ACE, matching the gate already enforced by parse_dacl().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix aperture mapping leak<br /> <br /> amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver<br /> fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to<br /> always return false, so iounmap(aper_base_kaddr) never runs on normal<br /> driver unload, leaving an orphaned entry in the x86 PAT interval tree.<br /> <br /> On connected_to_cpu hardware, the aperture is mapped write-back (WB) via<br /> ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC)<br /> over the same range. The WC vs WB conflict causes:<br /> <br /> ioremap error for 0x..., requested 0x1, got 0x0<br /> amdgpu: discovery failed: -2<br /> <br /> Fix by switching to devres-managed mappings so cleanup is guaranteed<br /> regardless of drm_dev_enter() state:<br /> <br /> - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For<br /> IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut,<br /> returning __va(offset) from the existing kernel direct map. No new<br /> ioremap VA or PAT entry is created, so there is nothing to orphan.<br /> <br /> - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action,<br /> guaranteeing cleanup at device_del() time.<br /> <br /> Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio()<br /> since the mapping is now devres-owned.<br /> <br /> v2: Remove redundant x86_64 guard (Lijo)<br /> <br /> (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: reject mapping a reserved doorbell to a new queue<br /> <br /> When creating an user-queue, the user space<br /> provides a doorbell BO handle and an offset within<br /> the bo to obtain a doorbell.<br /> <br /> However current implementation using xa_store_irq()<br /> to store a doorbell, which allows a later queue created<br /> with the same BO and offset parameters to overwrite an<br /> existing queue and doorbell mapping.<br /> <br /> This can cause problems like misrouting fence IRQ<br /> processing to a wrong queue, and mislead the cleanup<br /> process of one queue erasing the mapping of another queue.<br /> <br /> This commit fixes this issue by replacing xa_store_irq with<br /> xa_insert_irq, which rejects mapping a reserved<br /> doorbell to a newly created queue<br /> <br /> (cherry picked from commit 6244eae22966350db52faf9c1369d3b2ffc5de4e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Preserve rq tracking across local DSQ dispatch<br /> <br /> dispatch_to_local_dsq() can run from scx_bpf_dsq_move_to_local() while<br /> ops.dispatch() has recorded the current rq. Moving a task to a local DSQ<br /> may switch to the source or destination rq before synchronously invoking<br /> ops.dequeue() through the following path:<br /> <br /> SCX_CALL_OP(dispatch, rq)<br /> ops.dispatch()<br /> scx_bpf_dsq_move_to_local()<br /> scx_flush_dispatch_buf()<br /> finish_dispatch()<br /> dispatch_to_local_dsq()<br /> scx_dispatch_enqueue()<br /> local_dsq_post_enq()<br /> call_task_dequeue()<br /> SCX_CALL_OP_TASK(dequeue, locked_rq, ...)<br /> <br /> The nested callback saves the recorded rq and restores it on return. If<br /> the rq tracking does not follow the lock switch, update_locked_rq() can<br /> trigger the following lockdep assertion while restoring an rq which is<br /> no longer held:<br /> <br /> WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170<br /> Call Trace:<br /> scx_dispatch_enqueue+0x2b0/0x460<br /> dispatch_to_local_dsq+0x138/0x230<br /> scx_flush_dispatch_buf+0x1af/0x220<br /> scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0<br /> bpf__sched_ext_ops_dispatch+0x4b/0xa7<br /> do_pick_task_scx+0x3b6/0x910<br /> __pick_next_task+0x105/0x1f0<br /> __schedule+0x3e7/0x1980<br /> <br /> Introduce switch_rq_lock() to update the tracking state together with<br /> each rq lock handoff. Use it in dispatch_to_local_dsq(),<br /> move_remote_task_to_local_dsq() and the in-balance paths of<br /> scx_dsq_move(), ensuring that scx_locked_rq() consistently refers to the<br /> rq whose lock is actually held throughout the lock dance.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix race between registration and connection abortion<br /> <br /> This fixes this race:<br /> - thread a: io_uring_enter -&gt; register sqe -&gt;<br /> fuse_uring_create_ring_ent -&gt; allocate ent but doesn&amp;#39;t grab queue_ref<br /> yet<br /> - thread b: fuse_conn_destroy() -&gt; fuse_chan_abort() -&gt;<br /> fuse_uring_abort() is a no-op due to queue ref being 0<br /> - thread a: grabs the queue_ref, queue_ref is now 1, rest of<br /> fuse_uring_do_register() logic executes<br /> - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs<br /> and calls<br /> "wait_event(ring-&gt;stop_waitq, atomic_read(&amp;ring-&gt;queue_refs) == 0);"<br /> The abort/unmount thread will hang indefinitely in unkillable state as<br /> nothing will decrement queue_refs or wake stop_waitq, and the ring,<br /> queue, and ent are leaked.<br /> <br /> Fix this by checking fch-&gt;connected under fch-&gt;lock after the created<br /> ent has grabbed a ref count on the queue. This ensures that in the<br /> scenario above, it is guaranteed that we either release the queue ref<br /> and wake up stop_waitq (in case fuse_chan_wait_aborted() is already<br /> waiting) in fuse_uring_do_register() when we detect !fch-&gt;connected, or<br /> if the connection is aborted after the check, it is guaranteed that the<br /> async teardown worker will be running in the background cleaning up ents<br /> and decrementing the ent&amp;#39;s ref on the queue, which will unblock the<br /> eventual queue and ring teardown.