CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42305 – ext4: check dot and dotdot of dx_root before making dir indexed
https://notcve.org/view.php?id=CVE-2024-42305
In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue. • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db https://git.kernel.org/stable/c/19e13b4d7f0303186fcc891aba8d0de7c8fdbda8 https://git.kernel.org/stable/c/42d420517072028fb0eb852c358056b7717ba5aa https://git.kernel.org/stable/c/8afe06ed3be7a874b3cd82ef5f8959aca8d6429a https://git.kernel.org/stable/c/abb411ac991810c0bcbe51c2e76d2502bf611b5c https://git.kernel.org/stable/c/9d241b7a39af192d1bb422714a458982c7cc67a2 https://git.kernel.org/stable/c/cdd345321699042ece4a9d2e70754d239 •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-42304 – ext4: make sure the first directory block is not a hole
https://notcve.org/view.php?id=CVE-2024-42304
In the Linux kernel, the following vulnerability has been resolved: ext4: make sure the first directory block is not a hole The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported. After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash. Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad. • https://git.kernel.org/stable/c/3a17ca864baffc0c6f6e8aad525aa4365775a193 https://git.kernel.org/stable/c/4e19d6b65fb4fc42e352ce9883649e049da14743 https://git.kernel.org/stable/c/3f0307b0d2d8b333a6964fc4c820dc86896fd1cf https://git.kernel.org/stable/c/514631c2225c1fd556c799cc1893fb27b0f48f00 https://git.kernel.org/stable/c/7f1f86276515f6816a98f6ca3ef99c827d54642f https://git.kernel.org/stable/c/5021b7a5bdd6bb859eb648c3da71cdd6aae1d133 https://git.kernel.org/stable/c/d81d7e347d1f1f48a5634607d39eb90c161c8afe https://git.kernel.org/stable/c/e02f9941e8c011aa3eafa799def6a134c •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42301 – dev/parport: fix the array out-of-bounds risk
https://notcve.org/view.php?id=CVE-2024-42301
In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] • https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8 https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d https://git.kernel.org/stable/c/a44f88f7576bc1916d8d6293f5c62fbe7cbe03e0 https://git.kernel.org/stable/c/c719b393374d3763e64900ee19aaed767d5a08d6 https://git.kernel.org/stable/c/7f4da759092a1a6ce35fb085182d02de8cc4cc84 https://git.kernel.org/stable/c/b579ea3516c371ecf59d073772bc45dfd28c8a0e https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a https://git.kernel.org/stable/c/ab11dac93d2d568d151b1918d7b84c2d0 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42297 – f2fs: fix to don't dirty inode for readonly filesystem
https://notcve.org/view.php?id=CVE-2024-42297
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't dirty inode for readonly filesystem syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). • https://git.kernel.org/stable/c/2d2916516577f2239b3377d9e8d12da5e6ccdfcf https://git.kernel.org/stable/c/54162974aea37a8cae00742470a78c7f6bd6f915 https://git.kernel.org/stable/c/54bc4e88447e385c4d4ffa85d93e0dce628fcfa6 https://git.kernel.org/stable/c/ec56571b4b146a1cfbedab49d5fcaf19fe8bf4f1 https://git.kernel.org/stable/c/9ce8135accf103f7333af472709125878704fdd4 https://git.kernel.org/stable/c/e62ff092a42f4a1bae3b310cf46673b4f3aac3b5 https://git.kernel.org/stable/c/2434344559f6743efb3ac15d11af9a0db9543bd3 https://git.kernel.org/stable/c/192b8fb8d1c8ca3c87366ebbef599fa80 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42296 – f2fs: fix return value of f2fs_convert_inline_inode()
https://notcve.org/view.php?id=CVE-2024-42296
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix return value of f2fs_convert_inline_inode() If device is readonly, make f2fs_convert_inline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below: f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [inline] file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [inline] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/fs.h:2114 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/70f5ef5f33c333cfb286116fa3af74ac9bc84f1b https://git.kernel.org/stable/c/47a8ddcdcaccd9b891db4574795e46a33a121ac2 https://git.kernel.org/stable/c/077f0e24b27c4b44841593c7edbd1993be9eecb5 https://git.kernel.org/stable/c/1e7725814361c8c008d131db195cef8274ff26b8 https://git.kernel.org/stable/c/a8eb3de28e7a365690c61161e7a07a4fc7c60bbf •