CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47692 – nfsd: return -EINVAL when namelen is 0
https://notcve.org/view.php?id=CVE-2024-47692
In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? • https://git.kernel.org/stable/c/74725959c33c14114fdce1e36e3504d106584d53 https://git.kernel.org/stable/c/6d07040ae5c2214e39c7444d898039c9e655a79a https://git.kernel.org/stable/c/0f1d007bbea38a61cf9c5392708dc70ae9d84a3d https://git.kernel.org/stable/c/b7b7a8df41ef18862dd6b22289fb46c2c12398af https://git.kernel.org/stable/c/84a563d136faf514fdad1ade28d7a142fd313cb8 https://git.kernel.org/stable/c/318f70857caab3da9a6ada9bc8c1f4f7591b695e https://git.kernel.org/stable/c/766d5fbd78f7a52b3888449a0358760477b74602 https://git.kernel.org/stable/c/1ff8be8d008b9ddc8e7043fbddd37d5d4 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47691 – f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()
https://notcve.org/view.php?id=CVE-2024-47691
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 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 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) - f2fs_ioc_shutdown - f2fs_do_shutdown - f2fs_stop_gc_thread - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore. • https://git.kernel.org/stable/c/7950e9ac638e84518fbdd5c930939ad46a1068c5 https://git.kernel.org/stable/c/fc18e655b62ac6bc9f12f5de0d749b4a3fe1e812 https://git.kernel.org/stable/c/7c339dee7eb0f8e4cadc317c595f898ef04dae30 https://git.kernel.org/stable/c/d79343cd66343709e409d96b2abb139a0a55ce34 https://git.kernel.org/stable/c/c7f114d864ac91515bb07ac271e9824a20f5ed95 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-47690 – f2fs: get rid of online repaire on corrupted directory
https://notcve.org/view.php?id=CVE-2024-47690
In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs. • https://git.kernel.org/stable/c/510022a85839a8409d1e6a519bb86ce71a84f30a https://git.kernel.org/stable/c/e8d64f598eeb079c42a52deaa3a91312c736a49d https://git.kernel.org/stable/c/f4746f2d79507f65cfbde11d3c39ee8338aa50af https://git.kernel.org/stable/c/f9ce2f550d53d044ecfb5ce996406cf42cd6b84d https://git.kernel.org/stable/c/8be95cd607478d85fa4626e86f811e785905bcbf https://git.kernel.org/stable/c/bcefd0b0611f35b560d0a7281d87529fbe7a1e32 https://git.kernel.org/stable/c/884ee6dc85b959bc152f15bca80c30f06069e6c4 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47689 – f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()
https://notcve.org/view.php?id=CVE-2024-47689
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) - f2fs_handle_critical_error - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz • https://git.kernel.org/stable/c/b62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5 https://git.kernel.org/stable/c/ed1d478bf838820201f3fb67a1748fdf15954ea4 https://git.kernel.org/stable/c/649ec8b30df113042588bd3d3cd4e98bcb1091e0 https://git.kernel.org/stable/c/de43021c72993877a8f86f9fddfa0687609da5a4 https://git.kernel.org/stable/c/1f63f405c1a1a64b9c310388aad7055fb86b245c https://git.kernel.org/stable/c/930c6ab93492c4b15436524e704950b364b2930c •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47686 – ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()
https://notcve.org/view.php?id=CVE-2024-47686
In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read. • https://git.kernel.org/stable/c/9645ccc7bd7a16cd73c3be9dee70cd702b03be37 https://git.kernel.org/stable/c/7a5bd2fb92388c51d267f6ce57c40f1cca8af1e0 https://git.kernel.org/stable/c/66e78ade976dbd9bea09166aa8d66afc0963cde4 https://git.kernel.org/stable/c/27f493e141823db052586010c1532b70b164507c https://git.kernel.org/stable/c/ae59eaf36a1ad396e9f657ec9b8b52da6206ed5f https://git.kernel.org/stable/c/c7f06284a6427475e3df742215535ec3f6cd9662 •