Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn32_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` is<br /> null.<br /> <br /> The fix adds a check to ensure `dc-&gt;clk_mgr` is not null before<br /> accessing its functions. This prevents a potential null pointer<br /> dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed &amp;#39;dc-&gt;clk_mgr&amp;#39; could be null (see line 782)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn401_init_hw<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn401_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or<br /> `dc-&gt;clk_mgr-&gt;funcs` is null.<br /> <br /> The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is<br /> not null before accessing its functions. This prevents a potential null<br /> pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed &amp;#39;dc-&gt;clk_mgr&amp;#39; could be null (see line 225)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn30_init_hw<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn30_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or<br /> `dc-&gt;clk_mgr-&gt;funcs` is null.<br /> <br /> The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is<br /> not null before accessing its functions. This prevents a potential null<br /> pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed &amp;#39;dc-&gt;clk_mgr&amp;#39; could be null (see line 628)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check stream before comparing them<br /> <br /> [WHAT &amp; HOW]<br /> amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is<br /> necessary to check for null before dereferencing them.<br /> <br /> This fixes 1 FORWARD_NULL issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check phantom_stream before it is used<br /> <br /> dcn32_enable_phantom_stream can return null, so returned value<br /> must be checked before used.<br /> <br /> This fixes 1 NULL_RETURNS issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check null-initialized variables<br /> <br /> [WHAT &amp; HOW]<br /> drr_timing and subvp_pipe are initialized to null and they are not<br /> always assigned new values. It is necessary to check for null before<br /> dereferencing.<br /> <br /> This fixes 2 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Initialize denominators&amp;#39; default to 1<br /> <br /> [WHAT &amp; HOW]<br /> Variables used as denominators and maybe not assigned to other values,<br /> should not be 0. Change their default to 1 so they are never 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 /> jfs: Fix uninit-value access of new_ea in ea_buffer<br /> <br /> syzbot reports that lzo1x_1_do_compress is using uninit-value:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178<br /> <br /> ...<br /> <br /> Uninit was stored to memory at:<br /> ea_put fs/jfs/xattr.c:639 [inline]<br /> <br /> ...<br /> <br /> Local variable ea_buf created at:<br /> __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662<br /> __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934<br /> <br /> =====================================================<br /> <br /> The reason is ea_buf-&gt;new_ea is not initialized properly.<br /> <br /> Fix this by using memset to empty its content at the beginning<br /> in ea_get().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: Assign msm_gpu-&gt;pdev earlier to avoid nullptrs<br /> <br /> There are some cases, such as the one uncovered by Commit 46d4efcccc68<br /> ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")<br /> where<br /> <br /> msm_gpu_cleanup() : platform_set_drvdata(gpu-&gt;pdev, NULL);<br /> <br /> is called on gpu-&gt;pdev == NULL, as the GPU device has not been fully<br /> initialized yet.<br /> <br /> Turns out that there&amp;#39;s more than just the aforementioned path that<br /> causes this to happen (e.g. the case when there&amp;#39;s speedbin data in the<br /> catalog, but opp-supported-hw is missing in DT).<br /> <br /> Assigning msm_gpu-&gt;pdev earlier seems like the least painful solution<br /> to this, therefore do so.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/602742/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: check if leafidx greater than num leaves per dmap tree<br /> <br /> syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater<br /> than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.<br /> <br /> Shaggy:<br /> Modified sanity check to apply to control pages as well as leaf pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix uaf in dbFreeBits<br /> <br /> [syzbot reported]<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]<br /> BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752<br /> Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216<br /> <br /> CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> __mutex_lock_common kernel/locking/mutex.c:587 [inline]<br /> __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752<br /> dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390<br /> dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]<br /> dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409<br /> dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650<br /> jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100<br /> jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> <br /> Freed by task 5218:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object+0xe0/0x150 mm/kasan/common.c:240<br /> __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2252 [inline]<br /> slab_free mm/slub.c:4473 [inline]<br /> kfree+0x149/0x360 mm/slub.c:4594<br /> dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278<br /> jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247<br /> jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454<br /> reconfigure_super+0x445/0x880 fs/super.c:1083<br /> vfs_cmd_reconfigure fs/fsopen.c:263 [inline]<br /> vfs_fsconfig_locked fs/fsopen.c:292 [inline]<br /> __do_sys_fsconfig fs/fsopen.c:473 [inline]<br /> __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [Analysis]<br /> There are two paths (dbUnmount and jfs_ioc_trim) that generate race<br /> condition when accessing bmap, which leads to the occurrence of uaf.<br /> <br /> Use the lock s_umount to synchronize them, in order to avoid uaf caused<br /> by race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: add list empty check to avoid null pointer issue<br /> <br /> Add list empty check to avoid null pointer issues in some corner cases.<br /> - list_for_each_entry_safe()