CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40955 – ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()
https://notcve.org/view.php?id=CVE-2024-40955
In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops. • https://git.kernel.org/stable/c/7e170922f06bf46effa7c57f6035fc463d6edc7e https://git.kernel.org/stable/c/677ff4589f1501578fa903a25bb14831d0607992 https://git.kernel.org/stable/c/b829687ae1229224262bcabf49accfa2dbf8db06 https://git.kernel.org/stable/c/13df4d44a3aaabe61cd01d277b6ee23ead2a5206 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40954 – net: do not leave a dangling sk pointer, when socket creation fails
https://notcve.org/view.php?id=CVE-2024-40954
In the Linux kernel, the following vulnerability has been resolved: net: do not leave a dangling sk pointer, when socket creation fails It is possible to trigger a use-after-free by: * attaching an fentry probe to __sock_release() and the probe calling the bpf_get_socket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299 CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? __sock_gen_cookie (. • https://git.kernel.org/stable/c/c5dbb89fc2ac013afe67b9e4fcb3743c02b567cd https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069 https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5 https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9 https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 https://access.redhat.com/security/cve/CVE-2024-40954 https://bugzilla.redhat.com/show_bug.cgi?id=2297538 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40953 – KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
https://notcve.org/view.php?id=CVE-2024-40953
In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../.. • https://git.kernel.org/stable/c/217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 https://git.kernel.org/stable/c/11a772d5376aa6d3e2e69b5b5c585f79b60c0e17 https://git.kernel.org/stable/c/4c141136a28421b78f34969b25a4fa32e06e2180 https://git.kernel.org/stable/c/71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84 https://git.kernel.org/stable/c/82bd728a06e55f5b5f93d10ce67f4fe7e689853a https://git.kernel.org/stable/c/92c77807d938145c7c3350c944ef9f39d7f6017c https://git.kernel.org/stable/c/a937ef951bba72f48d2402451419d725d70dba20 https://git.kernel.org/stable/c/95c8dd79f3a14df96b3820b35b8399bd9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40952 – ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
https://notcve.org/view.php?id=CVE-2024-40952
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty() bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the following NULL pointer dereference in ocfs2_journal_dirty() since b_assoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits. [ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [ 134.366265] ? • https://git.kernel.org/stable/c/8887b94d93224e0ef7e1bc6369640e313b8b12f4 https://git.kernel.org/stable/c/0550ad87711f815b3d73e487ec58ca7d8f56edbc https://git.kernel.org/stable/c/72663d3e09091f431a0774227ca207c0358362dd https://git.kernel.org/stable/c/58f7e1e2c9e72c7974054c64c3abeac81c11f822 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40951 – ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()
https://notcve.org/view.php?id=CVE-2024-40951
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger() bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. Since ocfs2 hasn't set bh->b_assoc_map, it will trigger NULL pointer dereference when calling into ocfs2_abort_trigger(). Actually this was pointed out in history, see commit 74e364ad1b13. But I've made a mistake when reviewing commit 8887b94d9322 and then re-introduce this regression. Since we cannot revive bdev in buffer head, so fix this issue by initializing all types of ocfs2 triggers when fill super, and then get the specific ocfs2 trigger from ocfs2_caching_info when access journal. [joseph.qi@linux.alibaba.com: v2] Link: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com • https://git.kernel.org/stable/c/8887b94d93224e0ef7e1bc6369640e313b8b12f4 https://git.kernel.org/stable/c/67bcecd780609f471260a8c83fb0ae15f27734ce https://git.kernel.org/stable/c/eb63357ef229fae061ce7ce2839d558681c42f1a https://git.kernel.org/stable/c/685d03c3795378fca6a1b3d43581f7f1a3fc095f •