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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/7b24d41d47a6805c45378debf8bd115675d41da8 https://git.kernel.org/stable/c/dac398ed272a378d2f42ac68ae408333a51baf52 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/8ad8b531de79c348bcb8133e7f5e827b8 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49899 – drm/amd/display: Initialize denominators' default to 1
https://notcve.org/view.php?id=CVE-2024-49899
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. • https://git.kernel.org/stable/c/7f8e93b862aba08d540f1e9e03e0ceb4d0cfd5fb https://git.kernel.org/stable/c/b995c0a6de6c74656a0c39cd57a0626351b13e3c •