CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49905 – drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)
https://notcve.org/view.php?id=CVE-2024-49905
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252) • https://git.kernel.org/stable/c/bd0e24e5e608ccb9fdda300bb974496d6d8cf57d https://git.kernel.org/stable/c/75839e2365b666ff4e1b9047e442cab138eac4f6 https://git.kernel.org/stable/c/9132882eaae4d21d2fc5843b3308379a481ebdf0 https://git.kernel.org/stable/c/e4e26cbe34d7c1c1db5fb7b3101573c29866439f https://git.kernel.org/stable/c/cd9e9e0852d501f169aa3bb34e4b413d2eb48c37 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49904 – drm/amdgpu: add list empty check to avoid null pointer issue
https://notcve.org/view.php?id=CVE-2024-49904
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe() • https://git.kernel.org/stable/c/5ec731ef47f1dba34daad3e51a93de793f9319ac https://git.kernel.org/stable/c/8e87763946f708063d7e5303339598abbb8c5aac https://git.kernel.org/stable/c/4416377ae1fdc41a90b665943152ccd7ff61d3c5 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49903 – jfs: Fix uaf in dbFreeBits
https://notcve.org/view.php?id=CVE-2024-49903
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition. • https://git.kernel.org/stable/c/4ac58f7734937f3249da734ede946dfb3b1af5e4 https://git.kernel.org/stable/c/3126ccde51f51b0648c8cdccaf916e8bd062e972 https://git.kernel.org/stable/c/fd026b6b6758d5569705c02540b40f3bbf822b9a https://git.kernel.org/stable/c/e7ae14f7ee76c6ef5a48aebab1a278ad78f42619 https://git.kernel.org/stable/c/0c238da83f56bb895cab1e5851d034ac45b158d1 https://git.kernel.org/stable/c/4218b31ecc7af7e191768d32e32ed4386d8f9b76 https://git.kernel.org/stable/c/a9603a6f75df2fd8125cd208c98cfaa0fe3f7505 https://git.kernel.org/stable/c/95accb7183badca387f7a8d19a2475cf3 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49902 – jfs: check if leafidx greater than num leaves per dmap tree
https://notcve.org/view.php?id=CVE-2024-49902
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages. • https://git.kernel.org/stable/c/d76b9a4c283c7535ae7c7c9b14984e75402951e1 https://git.kernel.org/stable/c/35b91f15f44ce3c01eba058ccb864bb04743e792 https://git.kernel.org/stable/c/2451e5917c56be45d4add786e2a059dd9c2c37c4 https://git.kernel.org/stable/c/25d2a3ff02f22e215ce53355619df10cc5faa7ab https://git.kernel.org/stable/c/058aa89b3318be3d66a103ba7c68d717561e1dc6 https://git.kernel.org/stable/c/7fff9a9f866e99931cf6fa260288e55d01626582 https://git.kernel.org/stable/c/cb0eb10558802764f07de1dc439c4609e27cb4f0 https://git.kernel.org/stable/c/4a7bf6a01fb441009a6698179a739957e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49901 – drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs
https://notcve.org/view.php?id=CVE-2024-49901
In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/ • https://git.kernel.org/stable/c/9288a9676c529ad9c856096db68fad812499bc4a https://git.kernel.org/stable/c/9773737375b20070ea935203fd66cb9fa17c5acb https://git.kernel.org/stable/c/e8ac2060597a5768e4699bb61d604b4c09927b85 https://git.kernel.org/stable/c/16007768551d5bfe53426645401435ca8d2ef54f •