CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43882 – exec: Fix ToCToU between perm check and set-uid/gid usage
https://notcve.org/view.php?id=CVE-2024-43882
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. • https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759 https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64 https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1 https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43858 – jfs: Fix array-index-out-of-bounds in diFree
https://notcve.org/view.php?id=CVE-2024-43858
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00 https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862 https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80 https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9 https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28 https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7 https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43856 – dma: fix call order in dmam_free_coherent
https://notcve.org/view.php?id=CVE-2024-43856
In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 • https://git.kernel.org/stable/c/9ac7849e35f705830f7b016ff272b0ff1f7ff759 https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63 https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9 https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7 https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954 https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130 https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43854 – block: initialize integrity buffer to zero before writing it to media
https://notcve.org/view.php?id=CVE-2024-43854
In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. • https://git.kernel.org/stable/c/7ba1ba12eeef0aa7113beb16410ef8b7c748e18b https://git.kernel.org/stable/c/9f4af4cf08f9a0329ade3d938f55d2220c40d0a6 https://git.kernel.org/stable/c/129f95948a96105c1fad8e612c9097763e88ac5f https://git.kernel.org/stable/c/3fd11fe4f20756b4c0847f755a64cd96f8c6a005 https://git.kernel.org/stable/c/cf6b45ea7a8df0f61bded1dc4a8561ac6ad143d2 https://git.kernel.org/stable/c/d418313bd8f55c079a7da12651951b489a638ac1 https://git.kernel.org/stable/c/23a19655fb56f241e592041156dfb1c6d04da644 https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b198 • CWE-401: Missing Release of Memory after Effective Lifetime •
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 •