CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42311 – hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()
https://notcve.org/view.php?id=CVE-2024-42311
In the Linux kernel, the following vulnerability has been resolved: hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode() Syzbot reports uninitialized value access issue as below: loop0: detected capacity change from 0 to 64 ===================================================== BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it. • https://git.kernel.org/stable/c/f7316b2b2f11cf0c6de917beee8d3de728be24db https://git.kernel.org/stable/c/4a52861cd76e79f1a593beb23d096523eb9732c2 https://git.kernel.org/stable/c/10f7163bfb5f8b4e0c9c05a939f20b8540e33c65 https://git.kernel.org/stable/c/d55aae5c1730d6b70d5d8eaff00113cd34772ea3 https://git.kernel.org/stable/c/58d83fc160505a7009c39dec64effaac5129b971 https://git.kernel.org/stable/c/9c4e40b9b731220f9464975e49da75496e3865c4 https://git.kernel.org/stable/c/d3493d6f0dfb1ab5225b62faa77732983f2187a1 https://git.kernel.org/stable/c/26a2ed107929a855155429b11e1293b83 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42310 – drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
https://notcve.org/view.php?id=CVE-2024-42310
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. • https://git.kernel.org/stable/c/6a227d5fd6c4abe6a9226a40f6981825e9da5fbe https://git.kernel.org/stable/c/f392c36cebf4c1d6997a4cc2c0f205254acef42a https://git.kernel.org/stable/c/a658ae2173ab74667c009e2550455e6de5b33ddc https://git.kernel.org/stable/c/b6ac46a00188cde50ffba233e6efb366354a1de5 https://git.kernel.org/stable/c/08f45102c81ad8bc9f85f7a25e9f64e128edb87d https://git.kernel.org/stable/c/e74eb5e8089427c8c49e0dd5067e5f39ce3a4d56 https://git.kernel.org/stable/c/2d209b2f862f6b8bff549ede541590a8d119da23 https://git.kernel.org/stable/c/977ee4fe895e1729cd36cc26916bbb100 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42309 – drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
https://notcve.org/view.php?id=CVE-2024-42309
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. • https://git.kernel.org/stable/c/89c78134cc54dff016c83367912eb055637fa50c https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee https://git.kernel.org/stable/c/d6ad202f73f8edba0cbc0065aa57a79ffe8fdcdc https://git.kernel.org/stable/c/6735d02ead7dd3adf74eb8b70aebd09e0ce78ec9 https://git.kernel.org/stable/c/7e52c62ff029f95005915c0a11863b5fb5185c8c https://git.kernel.org/stable/c/f70ffeca546452d1acd3a70ada56ecb2f3e7f811 https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692 https://git.kernel.org/stable/c/475a5b3b7c8edf6e583a9eb59cf28ea77 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42307 – cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path
https://notcve.org/view.php?id=CVE-2024-42307
In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path Dan Carpenter reported a Smack static checker warning: fs/smb/client/cifsfs.c:1981 init_cifs() error: we previously assumed 'serverclose_wq' could be null (see line 1895) The patch which introduced the serverclose workqueue used the wrong oredering in error paths in init_cifs() for freeing it on errors. • https://git.kernel.org/stable/c/8c99dfb49bdc17edffc7ff3d46b400c8c291686c https://git.kernel.org/stable/c/6f17163b9339fac92023a1d9bef22128db3b9a4b https://git.kernel.org/stable/c/173217bd73365867378b5e75a86f0049e1069ee8 https://git.kernel.org/stable/c/40a5d14c9d3b585d55d3209fb5efe202dcaac926 https://git.kernel.org/stable/c/6018971710fdc7739f8655c1540832b4bb903671 https://git.kernel.org/stable/c/160235efb4f9b55212dedff5de0094c606c4b303 https://git.kernel.org/stable/c/3739d711246d8fbc95ff73dbdace9741cdce4777 https://git.kernel.org/stable/c/193cc89ea0ca1da311877d2b4bb5e9f03 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-42306 – udf: Avoid using corrupted block bitmap buffer
https://notcve.org/view.php?id=CVE-2024-42306
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid using corrupted block bitmap buffer When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not. • https://git.kernel.org/stable/c/7648ea9896b31aff38830d81188f5b7a1773e4a8 https://git.kernel.org/stable/c/4ac54312f623c6d2ca30c36c1ef530c11f5aff64 https://git.kernel.org/stable/c/099bf90d7fc4622da9fd4727f6d318a0f12d10be https://git.kernel.org/stable/c/6ac8f2c8362afd2baa8e7b9c946597589e587d22 https://git.kernel.org/stable/c/1e0d4adf17e7ef03281d7b16555e7c1508c8ed2d https://git.kernel.org/stable/c/f862a9049c3f6e73a5504a1ac10ffd5bc253ab55 https://git.kernel.org/stable/c/4622cc1b6d86013e01c56b60b092b5e4726c8e52 https://git.kernel.org/stable/c/cae9e59cc41683408b70b9ab569f86548 •