Vulnerabilities

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/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank()<br /> <br /> amdgpu_dm_crtc_set_vblank() dereferences acrtc_state-&gt;stream when<br /> vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before<br /> a stream is attached to it.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu]<br /> Call Trace:<br /> drm_vblank_enable<br /> drm_vblank_get<br /> drm_crtc_get_sequence_ioctl<br /> drm_ioctl_kernel<br /> drm_ioctl<br /> <br /> Reproduced by running VKCTS with WSI tests enabled on RADV.<br /> <br /> Guard the enable path on acrtc_state-&gt;stream being non-NULL, matching<br /> the existing checks in this function.<br /> <br /> (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Pad trailing CCA or EP11 message with zeros<br /> <br /> The both functions xcrb_msg_to_type6cprb_msgx() and<br /> xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a<br /> kernel buffer based on the message length. But on further processing<br /> the message is supposed to be 4 byte length adjusted. Thus up to 3<br /> bytes of uninitialized kernel memory are forwarded to further<br /> processing steps and may unwanted expose kernel memory to the crypto<br /> card firmware.<br /> <br /> This patch contains code to pad the gap between user space copied<br /> message and message buffer length sent down to further processing of<br /> the CCA or EP11 message to zeros.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: bounds-check buffer log item&amp;#39;s dirty bitmap<br /> <br /> xlog_recover_do_reg_buffer() replays each dirty region described by a<br /> buffer log item&amp;#39;s bitmap into the buffer read for that item:<br /> <br /> memcpy(xfs_buf_offset(bp, (uint)bit

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 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.