CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56586 – f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
https://notcve.org/view.php?id=CVE-2024-56586
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode. creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 asm_exc_invalid_op+0x16/0x20 f2fs_evict_inode+0x58c/0x610 evict+0x101/0x260 dispose_list+0x30/0x50 evict_inodes+0x140/0x190 generic_shutdown_super+0x2f/0x150 kill_block_super+0x11/0x40 kill_f2fs_super+0x7d/0x140 deactivate_locked_super+0x2a/0x70 cleanup_mnt+0xb3/0x140 task_work_run+0x61/0x90 The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows: dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir Let's redirty inode when there is not free segments during checkpoint is disable. • https://git.kernel.org/stable/c/ac8aaf78bd039fa1be0acaa8e84a56499f79d721 https://git.kernel.org/stable/c/dff561e4060d28edc9a2960d4a87f3c945a96aa3 https://git.kernel.org/stable/c/a365de2fbfbe1e6740bfb75ab5c3245cf7bbe4d7 https://git.kernel.org/stable/c/ef517d2d21c3d8e2ad35b2bb728bd1c90a31e617 https://git.kernel.org/stable/c/9669b28f81e0ec6305af7773846fbe2cef1e7d61 https://git.kernel.org/stable/c/9e28513fd2858911dcf47b84160a8824587536b6 https://git.kernel.org/stable/c/d5c367ef8287fb4d235c46a2f8c8d68715f3a0ca •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56585 – LoongArch: Fix sleeping in atomic context for PREEMPT_RT
https://notcve.org/view.php?id=CVE-2024-56585
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix sleeping in atomic context for PREEMPT_RT Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setup_tlb_handler()") changes the gfp flag from GFP_KERNEL to GFP_ATOMIC for alloc_pages_node(). However, for PREEMPT_RT kernels we can still get a "sleeping in atomic context" error: [ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.372268] preempt_count: 1, expected: 0 [ 0.372270] RCU nest depth: 1, expected: 1 [ 0.372272] 3 locks held by swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0 [ 0.372314] irq event stamp: 0 [ 0.372316] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.372322] hardirqs last disabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372329] softirqs last enabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372335] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891 [ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788 [ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003 [ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Call Trace: [ 0.372542] [<9000000005924778>] show_stack+0x38/0x180 [ 0.372548] [<90000000071519c4>] dump_stack_lvl+0x94/0xe4 [ 0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] rt_spin_lock+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] get_page_from_freelist+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] per_cpu_trap_init+0x114/0x140 [ 0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] start_secondary+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c This is because in PREEMPT_RT kernels normal spinlocks are replaced by rt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling NUMA optimization completely for PREEMPT_RT kernels. • https://git.kernel.org/stable/c/08715b741f9b2a925d6485491e4907f3b29bac70 https://git.kernel.org/stable/c/c5f89458a2ea0800866b9fc690d3fa8367dc8f8d https://git.kernel.org/stable/c/6575e0867bd478a5d7ef1783ca1e73160807d238 https://git.kernel.org/stable/c/88fd2b70120d52c1010257d36776876941375490 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56584 – io_uring/tctx: work around xa_store() allocation error issue
https://notcve.org/view.php?id=CVE-2024-56584
In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found. • https://git.kernel.org/stable/c/94ad56f61b873ffeebcc620d451eacfbdf9d40f0 https://git.kernel.org/stable/c/42882b583095dcf747da6e3af1daeff40e27033e https://git.kernel.org/stable/c/d5b2ddf1f90c7248eff9630b95895c8950f2f36d https://git.kernel.org/stable/c/7eb75ce7527129d7f1fee6951566af409a37a1c4 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56574 – media: ts2020: fix null-ptr-deref in ts2020_probe()
https://notcve.org/view.php?id=CVE-2024-56574
In the Linux kernel, the following vulnerability has been resolved: media: ts2020: fix null-ptr-deref in ts2020_probe() KASAN reported a null-ptr-deref issue when executing the following command: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed. Solve this problem by adding checks to platform data. • https://git.kernel.org/stable/c/dc245a5f9b5163511e0c164c8aa47848f07b75a9 https://git.kernel.org/stable/c/ced1c04e82e3ecc246b921b9733f0df0866aa50d https://git.kernel.org/stable/c/5a53f97cd5977911850b695add057f9965c1a2d6 https://git.kernel.org/stable/c/b6208d1567f929105011bcdfd738f59a6bdc1088 https://git.kernel.org/stable/c/dc03866b5f4aa2668946f8384a1e5286ae53bbaa https://git.kernel.org/stable/c/a2ed3b780f34e4a6403064208bc2c99d1ed85026 https://git.kernel.org/stable/c/901070571bc191d1d8d7a1379bc5ba9446200999 https://git.kernel.org/stable/c/4a058b34b52ed3feb1f3ff6fd26aefeee •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56570 – ovl: Filter invalid inodes with missing lookup function
https://notcve.org/view.php?id=CVE-2024-56570
In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. • https://git.kernel.org/stable/c/f9248e2f73fb4afe08324485e98c815ac084d166 https://git.kernel.org/stable/c/5f86e79c0b2287ffdabe6c1b305a36c4e0f40fe3 https://git.kernel.org/stable/c/749eac5a6687ec99116e0691d0d71225254654e3 https://git.kernel.org/stable/c/ff43d008bbf9b27ada434d6455f039a5ef6cee53 https://git.kernel.org/stable/c/065bf5dd21639f80e68450de16bda829784dbb8c https://git.kernel.org/stable/c/72014e7745cc8250bb8f27bd78694dfd3f1b5773 https://git.kernel.org/stable/c/c8b359dddb418c60df1a69beea01d1b3322bfe83 •