CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40956 – dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
https://notcve.org/view.php?id=CVE-2024-40956
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list. A vulnerability was found in the Linux kernel's DMA engine component in the irq_process_work_list() function. A possible use-after-free condition can occur during list iteration, which is because a descriptor may be freed while another thread is reusing it, potentially leading to access to freed memory. • https://git.kernel.org/stable/c/16e19e11228ba660d9e322035635e7dcf160d5c2 https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33 https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5 https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8 https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7 https://access.redhat.com/security/cve/CVE-2024-40956 https://bugzilla.redhat.com/show_bug.cgi?id=2297540 • CWE-416: Use After Free •
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 •