Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation<br /> <br /> This commit addresses a potential index out of bounds issue in the<br /> `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30<br /> color management module. The issue could occur when the index &amp;#39;i&amp;#39;<br /> exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds, the function returns<br /> false to indicate an error.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid use-after-free in ext4_ext_show_leaf()<br /> <br /> In ext4_find_extent(), path may be freed by error or be reallocated, so<br /> using a previously saved *ppath may have been freed and thus may trigger<br /> use-after-free, as follows:<br /> <br /> ext4_split_extent<br /> path = *ppath;<br /> ext4_split_extent_at(ppath)<br /> path = ext4_find_extent(ppath)<br /> ext4_split_extent_at(ppath)<br /> // ext4_find_extent fails to free path<br /> // but zeroout succeeds<br /> ext4_ext_show_leaf(inode, path)<br /> eh = path[depth].p_hdr<br /> // path use-after-free !!!<br /> <br /> Similar to ext4_split_extent_at(), we use *ppath directly as an input to<br /> ext4_ext_show_leaf(). Fix a spelling error by the way.<br /> <br /> Same problem in ext4_ext_handle_unwritten_extents(). Since &amp;#39;path&amp;#39; is only<br /> used in ext4_ext_show_leaf(), remove &amp;#39;path&amp;#39; and use *ppath directly.<br /> <br /> This issue is triggered only when EXT_DEBUG is defined and therefore does<br /> not affect functionality.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: ensure the fw_info is not null before using it<br /> <br /> This resolves the dereference null return value warning<br /> reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Initialize get_bytes_per_element&amp;#39;s default to 1<br /> <br /> Variables, used as denominators and maybe not assigned to other values,<br /> should not be 0. bytes_per_element_y &amp; bytes_per_element_c are<br /> initialized by get_bytes_per_element() which should never return 0.<br /> <br /> This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in degamma hardware format translation<br /> <br /> Fixes index out of bounds issue in<br /> `cm_helper_translate_curve_to_degamma_hw_format` function. The issue<br /> could occur when the index &amp;#39;i&amp;#39; exceeds the number of transfer function<br /> points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds the function returns<br /> false to indicate an error.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: aovid use-after-free in ext4_ext_insert_extent()<br /> <br /> As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is<br /> reallocated in ext4_ext_create_new_leaf(), we&amp;#39;ll use the stale path and<br /> cause UAF. Below is a sample trace with dummy values:<br /> <br /> ext4_ext_insert_extent<br /> path = *ppath = 2000<br /> ext4_ext_create_new_leaf(ppath)<br /> ext4_find_extent(ppath)<br /> path = *ppath = 2000<br /> if (depth &gt; path[0].p_maxdepth)<br /> kfree(path = 2000);<br /> *ppath = path = NULL;<br /> path = kcalloc() = 3000<br /> *ppath = 3000;<br /> return path;<br /> /* here path is still 2000, UAF! */<br /> eh = path[depth].p_hdr<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330<br /> Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179<br /> CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866<br /> Call Trace:<br /> <br /> ext4_ext_insert_extent+0x26d4/0x3330<br /> ext4_ext_map_blocks+0xe22/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> [...]<br /> <br /> Allocated by task 179:<br /> ext4_find_extent+0x81c/0x1f70<br /> ext4_ext_map_blocks+0x146/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> ext4_writepages+0x26d/0x4e0<br /> do_writepages+0x175/0x700<br /> [...]<br /> <br /> Freed by task 179:<br /> kfree+0xcb/0x240<br /> ext4_find_extent+0x7c0/0x1f70<br /> ext4_ext_insert_extent+0xa26/0x3330<br /> ext4_ext_map_blocks+0xe22/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> ext4_writepages+0x26d/0x4e0<br /> do_writepages+0x175/0x700<br /> [...]<br /> ==================================================================<br /> <br /> So use *ppath to update the path to avoid the above problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix slab-use-after-free in ext4_split_extent_at()<br /> <br /> We hit the following use-after-free:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0<br /> Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40<br /> CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724<br /> Call Trace:<br /> <br /> kasan_report+0x93/0xc0<br /> ext4_split_extent_at+0xba8/0xcc0<br /> ext4_split_extent.isra.0+0x18f/0x500<br /> ext4_split_convert_extents+0x275/0x750<br /> ext4_ext_handle_unwritten_extents+0x73e/0x1580<br /> ext4_ext_map_blocks+0xe20/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> <br /> Allocated by task 40:<br /> __kmalloc_noprof+0x1ac/0x480<br /> ext4_find_extent+0xf3b/0x1e70<br /> ext4_ext_map_blocks+0x188/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> <br /> Freed by task 40:<br /> kfree+0xf1/0x2b0<br /> ext4_find_extent+0xa71/0x1e70<br /> ext4_ext_insert_extent+0xa22/0x3260<br /> ext4_split_extent_at+0x3ef/0xcc0<br /> ext4_split_extent.isra.0+0x18f/0x500<br /> ext4_split_convert_extents+0x275/0x750<br /> ext4_ext_handle_unwritten_extents+0x73e/0x1580<br /> ext4_ext_map_blocks+0xe20/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> ==================================================================<br /> <br /> The flow of issue triggering is as follows:<br /> <br /> ext4_split_extent_at<br /> path = *ppath<br /> ext4_ext_insert_extent(ppath)<br /> ext4_ext_create_new_leaf(ppath)<br /> ext4_find_extent(orig_path)<br /> path = *orig_path<br /> read_extent_tree_block<br /> // return -ENOMEM or -EIO<br /> ext4_free_ext_path(path)<br /> kfree(path)<br /> *orig_path = NULL<br /> a. If err is -ENOMEM:<br /> ext4_ext_dirty(path + path-&gt;p_depth)<br /> // path use-after-free !!!<br /> b. If err is -EIO and we have EXT_DEBUG defined:<br /> ext4_ext_show_leaf(path)<br /> eh = path[depth].p_hdr<br /> // path also use-after-free !!!<br /> <br /> So when trying to zeroout or fix the extent length, call ext4_find_extent()<br /> to update the path.<br /> <br /> In addition we use *ppath directly as an ext4_ext_show_leaf() input to<br /> avoid possible use-after-free when EXT_DEBUG is defined, and to avoid<br /> unnecessary path updates.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix off by one issue in alloc_flex_gd()<br /> <br /> Wesley reported an issue:<br /> <br /> ==================================================================<br /> EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/resize.c:324!<br /> CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27<br /> RIP: 0010:ext4_resize_fs+0x1212/0x12d0<br /> Call Trace:<br /> __ext4_ioctl+0x4e0/0x1800<br /> ext4_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0x99/0xd0<br /> x64_sys_call+0x1206/0x20d0<br /> do_syscall_64+0x72/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ==================================================================<br /> <br /> While reviewing the patch, Honza found that when adjusting resize_bg in<br /> alloc_flex_gd(), it was possible for flex_gd-&gt;resize_bg to be bigger than<br /> flexbg_size.<br /> <br /> The reproduction of the problem requires the following:<br /> <br /> o_group = flexbg_size * 2 * n;<br /> o_size = (o_group + 1) * group_size;<br /> n_group: [o_group + flexbg_size, o_group + flexbg_size * 2)<br /> o_size = (n_group + 1) * group_size;<br /> <br /> Take n=0,flexbg_size=16 as an example:<br /> <br /> last:15<br /> |o---------------|--------------n-|<br /> o_group:0 resize to n_group:30<br /> <br /> The corresponding reproducer is:<br /> <br /> img=test.img<br /> rm -f $img<br /> truncate -s 600M $img<br /> mkfs.ext4 -F $img -b 1024 -G 16 8M<br /> dev=`losetup -f --show $img`<br /> mkdir -p /tmp/test<br /> mount $dev /tmp/test<br /> resize2fs $dev 248M<br /> <br /> Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()<br /> to prevent the issue from happening again.<br /> <br /> [ Note: another reproucer which this commit fixes is:<br /> <br /> img=test.img<br /> rm -f $img<br /> truncate -s 25MiB $img<br /> mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img<br /> truncate -s 3GiB $img<br /> dev=`losetup -f --show $img`<br /> mkdir -p /tmp/test<br /> mount $dev /tmp/test<br /> resize2fs $dev 3G<br /> umount $dev<br /> losetup -d $dev<br /> <br /> -- TYT ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: omapdrm: Add missing check for alloc_ordered_workqueue<br /> <br /> As it may return NULL pointer and cause NULL pointer dereference. Add check<br /> for the return value of alloc_ordered_workqueue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: update orig_path in ext4_find_extent()<br /> <br /> In ext4_find_extent(), if the path is not big enough, we free it and set<br /> *orig_path to NULL. But after reallocating and successfully initializing<br /> the path, we don&amp;#39;t update *orig_path, in which case the caller gets a<br /> valid path but a NULL ppath, and this may cause a NULL pointer dereference<br /> or a path memory leak. For example:<br /> <br /> ext4_split_extent<br /> path = *ppath = 2000<br /> ext4_find_extent<br /> if (depth &gt; path[0].p_maxdepth)<br /> kfree(path = 2000);<br /> *orig_path = path = NULL;<br /> path = kcalloc() = 3000<br /> ext4_split_extent_at(*ppath = NULL)<br /> path = *ppath;<br /> ex = path[depth].p_ext;<br /> // NULL pointer dereference!<br /> <br /> ==================================================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847<br /> RIP: 0010:ext4_split_extent_at+0x6d/0x560<br /> Call Trace:<br /> <br /> ext4_split_extent.isra.0+0xcb/0x1b0<br /> ext4_ext_convert_to_initialized+0x168/0x6c0<br /> ext4_ext_handle_unwritten_extents+0x325/0x4d0<br /> ext4_ext_map_blocks+0x520/0xdb0<br /> ext4_map_blocks+0x2b0/0x690<br /> ext4_iomap_begin+0x20e/0x2c0<br /> [...]<br /> ==================================================================<br /> <br /> Therefore, *orig_path is updated when the extent lookup succeeds, so that<br /> the caller can safely use path or *ppath.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix double brelse() the buffer of the extents path<br /> <br /> In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been<br /> released, otherwise it may be released twice. An example of what triggers<br /> this is as follows:<br /> <br /> split2 map split1<br /> |--------|-------|--------|<br /> <br /> ext4_ext_map_blocks<br /> ext4_ext_handle_unwritten_extents<br /> ext4_split_convert_extents<br /> // path-&gt;p_depth == 0<br /> ext4_split_extent<br /> // 1. do split1<br /> ext4_split_extent_at<br /> |ext4_ext_insert_extent<br /> | ext4_ext_create_new_leaf<br /> | ext4_ext_grow_indepth<br /> | le16_add_cpu(&amp;neh-&gt;eh_depth, 1)<br /> | ext4_find_extent<br /> | // return -ENOMEM<br /> |// get error and try zeroout<br /> |path = ext4_find_extent<br /> | path-&gt;p_depth = 1<br /> |ext4_ext_try_to_merge<br /> | ext4_ext_try_to_merge_up<br /> | path-&gt;p_depth = 0<br /> | brelse(path[1].p_bh) ---&gt; not set to NULL here<br /> |// zeroout success<br /> // 2. update path<br /> ext4_find_extent<br /> // 3. do split2<br /> ext4_split_extent_at<br /> ext4_ext_insert_extent<br /> ext4_ext_create_new_leaf<br /> ext4_ext_grow_indepth<br /> le16_add_cpu(&amp;neh-&gt;eh_depth, 1)<br /> ext4_find_extent<br /> path[0].p_bh = NULL;<br /> path-&gt;p_depth = 1<br /> read_extent_tree_block ---&gt; return err<br /> // path[1].p_bh is still the old value<br /> ext4_free_ext_path<br /> ext4_ext_drop_refs<br /> // path-&gt;p_depth == 1<br /> brelse(path[1].p_bh) ---&gt; brelse a buffer twice<br /> <br /> Finally got the following WARRNING when removing the buffer from lru:<br /> <br /> ============================================<br /> VFS: brelse: Trying to free free buffer<br /> WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90<br /> CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716<br /> RIP: 0010:__brelse+0x58/0x90<br /> Call Trace:<br /> <br /> __find_get_block+0x6e7/0x810<br /> bdev_getblk+0x2b/0x480<br /> __ext4_get_inode_loc+0x48a/0x1240<br /> ext4_get_inode_loc+0xb2/0x150<br /> ext4_reserve_inode_write+0xb7/0x230<br /> __ext4_mark_inode_dirty+0x144/0x6a0<br /> ext4_ext_insert_extent+0x9c8/0x3230<br /> ext4_ext_map_blocks+0xf45/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> ============================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: fix UAF around queue destruction<br /> <br /> We currently do stuff like queuing the final destruction step on a<br /> random system wq, which will outlive the driver instance. With bad<br /> timing we can teardown the driver with one or more work workqueue still<br /> being alive leading to various UAF splats. Add a fini step to ensure<br /> user queues are properly torn down. At this point GuC should already be<br /> nuked so queue itself should no longer be referenced from hw pov.<br /> <br /> v2 (Matt B)<br /> - Looks much safer to use a waitqueue and then just wait for the<br /> xa_array to become empty before triggering the drain.<br /> <br /> (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)