Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix UVD decode image min size calculation<br /> <br /> This needs to use pitch instead of width. Also reject pitch<br /> over 4096 to avoid overflow.<br /> <br /> (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate GEM_CREATE domain combinations<br /> <br /> AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK,<br /> but did not validate domain combinations. Userspace could combine<br /> CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making<br /> amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and<br /> hit BUG_ON().<br /> <br /> Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/<br /> VRAM domains to be specified one at a time. Return -EINVAL for invalid<br /> combinations in amdgpu_gem_create_ioctl().<br /> <br /> v2: Rename helper from amdgpu_gem_domain_valid() to<br /> amdgpu_gem_are_domains_valid() (Christian)<br /> <br /> (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing<br /> <br /> The zcrypt_msgtype6_send_ep11_cprb() function uses fragile struct<br /> overlays to access and modify the domain field in the EP11 CPRB<br /> payload, creating maintainability and security concerns:<br /> 1. Struct overlay approach (pld_hdr) assumes fixed payload structure<br /> and doesn&amp;#39;t validate the actual ASN.1 encoding.<br /> 2. Complex length format detection logic is error-prone and doesn&amp;#39;t<br /> properly validate bounds at each parsing step.<br /> 3. Direct struct member access bypasses proper ASN.1 validation.<br /> <br /> Fix by replacing struct overlays with explicit ASN.1 parsing that<br /> validates each field (payload tag/length, function tag/length/value,<br /> optional domain tag/length/value) with proper bounds checking at every<br /> step. Add asn1_int_encode() helper function to safely write integer<br /> values with correct endianness conversion. This makes the code<br /> consistent with the validation pattern introduced with the rework of<br /> the xcrb_msg_to_type6_ep11cprb_msgx() function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Improve EP11 CPRB length and overflow checks<br /> <br /> The xcrb_msg_to_type6_ep11cprb_msgx() function lacks proper input<br /> validation, creating security vulnerabilities:<br /> 1. Missing minimum size validation: The ep11_cprb structure and<br /> subsequent payload fields (pld_tag, pld_lenfmt) are copied from<br /> userspace without verifying sufficient buffer length.<br /> 2. Arithmetic overflow in length calculations: CEIL4 alignment could<br /> overflow, bypassing size checks and enabling buffer overflows.<br /> 3. The payload is asn1 encoded but the function just uses a simple c<br /> struct overlay to access some fields of the payload.<br /> <br /> Fix by using size_t for length calculations, adding U32_MAX boundary<br /> checks after alignment, and validating minimum request size and<br /> minimum reply size before copying from userspace. Do a very simple<br /> asn1 parsing of the payload up to the function value field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Improve CCA CPRB length and overflow checks<br /> <br /> The xcrb_msg_to_type6cprb_msgx() function lacks proper input<br /> validation, creating security vulnerabilities:<br /> 1. Integer overflow after CEIL4 alignment: Signed int variables could<br /> overflow during 4-byte boundary alignment, causing undersized<br /> buffer allocations or incorrect bounds checking.<br /> 2. Missing minimum size validation: The CPRBX structure is copied from<br /> userspace without verifying sufficient buffer length. Undersized<br /> buffers cause uninitialized memory access when reading structure<br /> fields like cprbx.cprb_len and cprbx.domain.<br /> 3. Arithmetic overflow in sum calculations: Adding control block and<br /> data block sizes could overflow, bypassing size checks and enabling<br /> buffer overflows.<br /> <br /> Fix by using size_t for length calculations, adding U32_MAX boundary<br /> checks after alignment, validating minimum control block size before<br /> copying from userspace, and detecting sum calculation overflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: disallow multiple FENCE chunks in one submit<br /> <br /> amdgpu_cs_pass1() dispatches on chunk_id once per chunk without<br /> rejecting repeated ids. p-&gt;uf_bo is a single-slot field, so a<br /> submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs<br /> amdgpu_cs_p1_user_fence() twice, and the second run overwrites<br /> p-&gt;uf_bo with a freshly referenced BO without dropping the reference<br /> taken by the first.<br /> <br /> amdgpu_cs_parser_fini() only unrefs the final p-&gt;uf_bo, so every FENCE<br /> chunk but the last leaks a BO reference. The leaked BO outlives handle<br /> close and process exit.<br /> <br /> Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc<br /> ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did<br /> for p-&gt;bo_list.<br /> <br /> (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix another iunlink infinite loop bug in online fsck<br /> <br /> xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the<br /> incore prev and next unlinked list pointers based on what it finds on<br /> disk and in memory before we move on to relinking the truly lost inodes<br /> back into the unlinked list. However, it&amp;#39;s still vulnerable to infinite<br /> loops that come in via the next_unlinked pointers.<br /> <br /> Fix this problem by remembering which inodes we&amp;#39;ve already seen and<br /> checking new agino pointers against that. If a bit is already set,<br /> either this is a loop or the inode has nonzero link count. We&amp;#39;ll deal<br /> with the second case in a subsequent patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t walk off the end of a null sc-&gt;sa.agi_bp in AGI repair<br /> <br /> LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket<br /> tries to walk ragi-&gt;sc-&gt;sa.agi_bp to rebuild the unlinked inode lists.<br /> Unfortunately, it&amp;#39;s possible for agi_bp to be null if the buffer<br /> verifier fails, so we have to use ragi-&gt;agi_bp (which skips verifier<br /> checks) instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t double-lock when deleting a self-referential directory<br /> <br /> LOLLM notices that the dirtree scrubber can detect a directory that<br /> refers to itself. In this case, it&amp;#39;s not correct for the directory tree<br /> repair code to try to iolock/ilock both sc-&gt;ip and dp, because they&amp;#39;re<br /> the same inode. Fix this by detecting that corner case and handling it<br /> appropriately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: avoid UAF on sc-&gt;tempip in xrep_tempfile_create<br /> <br /> LOLLM noticed a potential UAF if the tempfile creation code fails after<br /> it set sc-&gt;tempip. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix off-by-one in rtrefcount btree root level validation<br /> <br /> xfs_rtrefcountbt_compute_maxlevels() sets<br /> <br /> mp-&gt;m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1;<br /> <br /> where the trailing "+ 1" already accounts for the inode-root level, so the<br /> deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must<br /> satisfy bc_nlevels " instead of "&gt;=", so a<br /> crafted rtreflink (metadir + realtime + reflink) image whose<br /> /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on<br /> mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1,<br /> exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is<br /> sized for exactly bc_maxlevels entries, the first btree op on such a cursor<br /> indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is<br /> reached by the first rtrefcount cursor built after mount, via log/CoW<br /> recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an<br /> FS_IOC_GETFSMAP over the realtime device.<br /> <br /> Reject a root level equal to m_rtrefc_maxlevels, matching the "&gt;=" form<br /> already used by the sibling data-device refcount/rmap verifiers and the<br /> in-memory rtrmap verifier.<br /> <br /> BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101)<br /> Write of size 2 at addr ffff888018391658 by task exploit/144<br /> xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101)<br /> xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308)<br /> xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113)<br /> xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085)<br /> xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551)<br /> xfs_mountfs (fs/xfs/xfs_mount.c:1158)<br /> xfs_fs_fill_super (fs/xfs/xfs_super.c:1940)<br /> get_tree_bdev_flags (fs/super.c:1634)<br /> vfs_get_tree (fs/super.c:1694)<br /> path_mount (fs/namespace.c:4161)<br /> __x64_sys_mount (fs/namespace.c:4367)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216<br /> The buggy address is located 8 bytes to the right of<br /> allocated 216-byte region [ffff888018391578, ffff888018391650)<br /> Kernel panic - not syncing: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix ilock leak on error in xfs_dq_get_next_id<br /> <br /> xfs_dq_get_next_id() takes the quota inode ILOCK before calling<br /> xfs_iread_extents(). If xfs_iread_extents() fails, the function returns<br /> immediately without releasing the lock, leaking the quota inode ILOCK.<br /> This can leave the quota inode locked and cause subsequent quota<br /> operations to hang.<br /> <br /> Fix this by jumping to a common unlock path on error instead of returning<br /> directly.