Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vivid: fix buffer overwrite when using &gt; 32 buffers<br /> <br /> The maximum number of buffers that can be requested was increased to<br /> 64 for the video capture queue. But video capture used a must_blank<br /> array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an<br /> out-of-bounds write when using buffer indices &gt;= 32.<br /> <br /> Create a new define MAX_VID_CAP_BUFFERS that is used to access the<br /> must_blank array and set max_num_buffers for the video capture queue.<br /> <br /> This solves a crash reported by:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=219258

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()<br /> <br /> Avoid a possible buffer overflow if size is larger than 4K.<br /> <br /> (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix a crash if blk_alloc_disk fails<br /> <br /> If blk_alloc_disk fails, the variable md-&gt;disk is set to an error value.<br /> cleanup_mapped_device will see that md-&gt;disk is non-NULL and it will<br /> attempt to access it, causing a crash on this statement<br /> "md-&gt;disk-&gt;private_data = NULL;".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: check outstanding simultaneous SMB operations<br /> <br /> If Client send simultaneous SMB operations to ksmbd, It exhausts too much<br /> memory through the "ksmbd_work_cache”. It will cause OOM issue.<br /> ksmbd has a credit mechanism but it can&amp;#39;t handle this problem. This patch<br /> add the check if it exceeds max credits to prevent this problem by assuming<br /> that one smb request consumes at least one credit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix potential out-of-bounds access on the first resume<br /> <br /> Out-of-bounds access occurs if the fast device is expanded unexpectedly<br /> before the first-time resume of the cache table. This happens because<br /> expanding the fast device requires reloading the cache table for<br /> cache_create to allocate new in-core data structures that fit the new<br /> size, and the check in cache_preresume is not performed during the<br /> first resume, leading to the issue.<br /> <br /> Reproduce steps:<br /> <br /> 1. prepare component devices:<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> <br /> 2. load a cache table of 512 cache blocks, and deliberately expand the<br /> fast device before resuming the cache, making the in-core data<br /> structures inadequate.<br /> <br /> dmsetup create cache --notable<br /> dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup resume cdata<br /> dmsetup resume cache<br /> <br /> 3. suspend the cache to write out the in-core dirty bitset and hint<br /> array, leading to out-of-bounds access to the dirty bitset at offset<br /> 0x40:<br /> <br /> dmsetup suspend cache<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80<br /> Read of size 8 at addr ffffc90000085040 by task dmsetup/90<br /> <br /> (...snip...)<br /> The buggy address belongs to the virtual mapping at<br /> [ffffc90000085000, ffffc90000087000) created by:<br /> cache_ctr+0x176a/0x35f0<br /> <br /> (...snip...)<br /> Memory state around the buggy address:<br /> ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> <br /> Fix by checking the size change on the first resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix out-of-bounds access to the dirty bitset when resizing<br /> <br /> dm-cache checks the dirty bits of the cache blocks to be dropped when<br /> shrinking the fast device, but an index bug in bitset iteration causes<br /> out-of-bounds access.<br /> <br /> Reproduce steps:<br /> <br /> 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds<br /> access to the dirty bitset (offset 0x80)<br /> <br /> dmsetup suspend cache<br /> dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup resume cdata<br /> dmsetup resume cache<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0<br /> Read of size 8 at addr ffffc900000f3080 by task dmsetup/131<br /> <br /> (...snip...)<br /> The buggy address belongs to the virtual mapping at<br /> [ffffc900000f3000, ffffc900000f5000) created by:<br /> cache_ctr+0x176a/0x35f0<br /> <br /> (...snip...)<br /> Memory state around the buggy address:<br /> ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> <br /> Fix by making the index post-incremented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix the missing xa_store error check<br /> <br /> xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot<br /> be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed,<br /> so check error for xa_store() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation<br /> <br /> When sealing or unsealing a key blob we currently do not wait for<br /> the AEAD cipher operation to finish and simply return after submitting<br /> the request. If there is some load on the system we can exit before<br /> the cipher operation is done and the buffer we read from/write to<br /> is already removed from the stack. This will e.g. result in NULL<br /> pointer dereference errors in the DCP driver during blob creation.<br /> <br /> Fix this by waiting for the AEAD cipher operation to finish before<br /> resuming the seal and unseal calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-tpg: prevent the risk of a division by zero<br /> <br /> As reported by Coverity, the logic at tpg_precalculate_line()<br /> blindly rescales the buffer even when scaled_witdh is equal to<br /> zero. If this ever happens, this will cause a division by zero.<br /> <br /> Instead, add a WARN_ON_ONCE() to trigger such cases and return<br /> without doing any precalculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp<br /> <br /> ksmbd_user_session_put should be called under smb3_preauth_hash_rsp().<br /> It will avoid freeing session before calling smb3_preauth_hash_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create<br /> <br /> There is a race condition between ksmbd_smb2_session_create and<br /> ksmbd_expire_session. This patch add missing sessions_table_lock<br /> while adding/deleting session from global session table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix flushing uninitialized delayed_work on cache_ctr error<br /> <br /> An unexpected WARN_ON from flush_work() may occur when cache creation<br /> fails, caused by destroying the uninitialized delayed_work waker in the<br /> error path of cache_create(). For example, the warning appears on the<br /> superblock checksum error.<br /> <br /> Reproduce steps:<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> Kernel logs:<br /> <br /> (snip)<br /> WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890<br /> <br /> Fix by pulling out the cancel_delayed_work_sync() from the constructor&amp;#39;s<br /> error path. This patch doesn&amp;#39;t affect the use-after-free fix for<br /> concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix<br /> UAF in destroy()")) as cache_dtr is not changed.