CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49867 – btrfs: wait for fixup workers before stopping cleaner kthread during umount
https://notcve.org/view.php?id=CVE-2024-49867
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 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 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: 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 mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated--- • https://git.kernel.org/stable/c/cd686dfff63f27d712877aef5b962fbf6b8bc264 https://git.kernel.org/stable/c/a71349b692ab34ea197949e13e3cc42570fe73d9 https://git.kernel.org/stable/c/70b60c8d9b42763d6629e44f448aa5d8ae477d61 https://git.kernel.org/stable/c/4c98fe0dfa2ae83c4631699695506d8941db4bfe https://git.kernel.org/stable/c/9da40aea63f8769f28afb91aea0fac4cf6fbbb65 https://git.kernel.org/stable/c/ed87190e9d9c80aad220fb6b0b03a84d22e2c95b https://git.kernel.org/stable/c/bf0de0f9a0544c11f96f93206da04ab87dcea1f4 https://git.kernel.org/stable/c/65d11eb276836d49003a8060cf31fa228 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49859 – f2fs: fix to check atomic_file in f2fs ioctl interfaces
https://notcve.org/view.php?id=CVE-2024-49859
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it. • https://git.kernel.org/stable/c/26b07bd2e1f124b0e430c8d250023f7205c549c3 https://git.kernel.org/stable/c/7cb51731f24b216b0b87942f519f2c67a17107ee https://git.kernel.org/stable/c/10569b682ebe9c75ef06ddd322ae844e9be6374b https://git.kernel.org/stable/c/d6f08c88047accc6127dddb6798a3ff11321539d https://git.kernel.org/stable/c/bfe5c02654261bfb8bd9cb174a67f3279ea99e58 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49858 – efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
https://notcve.org/view.php?id=CVE-2024-49858
In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. • https://git.kernel.org/stable/c/f76b69ab9cf04358266e3cea5748c0c2791fbb08 https://git.kernel.org/stable/c/11690d7e76842f29b60fbb5b35bc97d206ea0e83 https://git.kernel.org/stable/c/5b22c038fb2757c652642933de5664da471f8cb7 https://git.kernel.org/stable/c/19fd2f2c5fb36b61506d3208474bfd8fdf1cada3 https://git.kernel.org/stable/c/38d9b07d99b789efb6d8dda21f1aaad636c38993 https://git.kernel.org/stable/c/2e6871a632a99d9b9e2ce3a7847acabe99e5a26e https://git.kernel.org/stable/c/77d48d39e99170b528e4f2e9fc5d1d64cdedd386 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47757 – nilfs2: fix potential oob read in nilfs_btree_check_delete()
https://notcve.org/view.php?id=CVE-2024-47757
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case. • https://git.kernel.org/stable/c/17c76b0104e4a6513983777e1a17e0297a12b0c4 https://git.kernel.org/stable/c/f3a9859767c7aea758976f5523903d247e585129 https://git.kernel.org/stable/c/ed76d381dae125b81d09934e365391a656249da8 https://git.kernel.org/stable/c/d20674f31626e0596ae4c1d9401dfb6739b81b58 https://git.kernel.org/stable/c/c4f8554996e8ada3be872dfb8f60e93bcf15fb27 https://git.kernel.org/stable/c/a8abfda768b9f33630cfbc4af6c4214f1e5681b0 https://git.kernel.org/stable/c/257f9e5185eb6de83377caea686c306e22e871f2 https://git.kernel.org/stable/c/a33e967b681e088a125b979975c93e345 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47749 – RDMA/cxgb4: Added NULL check for lookup_atid
https://notcve.org/view.php?id=CVE-2024-47749
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/cfdda9d764362ab77b11a410bb928400e6520d57 https://git.kernel.org/stable/c/b12e25d91c7f97958341538c7dc63ee49d01548f https://git.kernel.org/stable/c/4e1fe68d695af367506ea3c794c5969630f21697 https://git.kernel.org/stable/c/dd598ac57dcae796cb58551074660c39b43fb155 https://git.kernel.org/stable/c/b11318dc8a1ec565300bb1a9073095af817cc508 https://git.kernel.org/stable/c/39cb9f39913566ec5865581135f3e8123ad1aee1 https://git.kernel.org/stable/c/0d50ae281a1712b9b2ca72830a96b8f11882358d https://git.kernel.org/stable/c/54aaa3ed40972511e423b604324b88142 •