CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/65d11eb276836d49003a8060cf31fa2284ad1047 https://git.kernel.org/stable/c/41fd1e94066a815a7ab0a7025359e9b40e4b3576 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49863 – vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
https://notcve.org/view.php?id=CVE-2024-49863
In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: <TASK> ? show_regs+0x86/0xa0 ? • https://git.kernel.org/stable/c/3f8ca2e115e55af4c15d97dda635e948d2e380be https://git.kernel.org/stable/c/6592347f06e2b19a624270a85ad4b3ae48c3b241 https://git.kernel.org/stable/c/46128370a72c431df733af5ebb065c4d48c9ad39 https://git.kernel.org/stable/c/ace9c778a214da9c98d7b69d904d1b0816f4f681 https://git.kernel.org/stable/c/25613e6d9841a1f9fb985be90df921fa99f800de https://git.kernel.org/stable/c/00fb5b23e1c9cdbe496f5cd6b40367cb895f6c93 https://git.kernel.org/stable/c/61517f33e76d2c5247c1e61e668693afe5b67e6f https://git.kernel.org/stable/c/221af82f606d928ccef19a16d35633c63 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49861 – bpf: Fix helper writes to read-only maps
https://notcve.org/view.php?id=CVE-2024-49861
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in ! • https://git.kernel.org/stable/c/57c3bb725a3dd97d960d7e1cd0845d88de53217f https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0 https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5 https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49860 – ACPI: sysfs: validate return type of _STR method
https://notcve.org/view.php?id=CVE-2024-49860
In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory. • https://git.kernel.org/stable/c/d1efe3c324ead77d3f6cd85093b50f6bd2e17aba https://git.kernel.org/stable/c/4b081991c4363e072e1748efed0bbec8a77daba5 https://git.kernel.org/stable/c/0cdfb9178a3bba843c95c2117c82c15f1a64b9ce https://git.kernel.org/stable/c/5c8d007c14aefc3f2ddf71e4c40713733dc827be https://git.kernel.org/stable/c/f0921ecd4ddc14646bb5511f49db4d7d3b0829f0 https://git.kernel.org/stable/c/f51e5a88f2e7224858b261546cf6b3037dfb1323 https://git.kernel.org/stable/c/f51f711d36e61fbb87c67b524fd200e05172668d https://git.kernel.org/stable/c/4bb1e7d027413835b086aed35bc3f0713 •
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 •