CVSS: -EPSS: %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: %CPEs: 7EXPL: 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/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/95accb7183badca387f7a8d19a2475cf3089f148 https://git.kernel.org/stable/c/d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 •
CVSS: -EPSS: %CPEs: 7EXPL: 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/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/4a7bf6a01fb441009a6698179a739957efd88e38 https://git.kernel.org/stable/c/d64ff0d2306713ff084d4b09f84ed1a8c75ecc32 •
CVSS: -EPSS: %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 •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2024-49900 – jfs: Fix uninit-value access of new_ea in ea_buffer
https://notcve.org/view.php?id=CVE-2024-49900
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get(). • https://git.kernel.org/stable/c/8b1dcf25c26d42e4a68c4725ce52a0543c7878cc https://git.kernel.org/stable/c/d7444f91a9f93eaa48827087ed0f3381c194181d https://git.kernel.org/stable/c/6041536d18c5f51a84bc37cd568cbab61870031e https://git.kernel.org/stable/c/c076b3746224982eebdba5c9e4b1467e146c0d64 https://git.kernel.org/stable/c/7c244d5b48284a770d96ff703df2dfeadf804a73 https://git.kernel.org/stable/c/8ad8b531de79c348bcb8133e7f5e827b884226af https://git.kernel.org/stable/c/2b59ffad47db1c46af25ccad157bb3b25147c35c •