CVSS: -EPSS: 0%CPEs: 4EXPL: 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/92c77807d938145c7c3350c944ef9f39d7f6017c https://git.kernel.org/stable/c/a937ef951bba72f48d2402451419d725d70dba20 https://git.kernel.org/stable/c/95c8dd79f3a14df96b3820b35b8399bd91b2be60 https://git.kernel.org/stable/c/49f683b41f28918df3e51ddc0d928cb2e934ccdb •
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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40949 – mm: shmem: fix getting incorrect lruvec when replacing a shmem folio
https://notcve.org/view.php?id=CVE-2024-40949
In the Linux kernel, the following vulnerability has been resolved: mm: shmem: fix getting incorrect lruvec when replacing a shmem folio When testing shmem swapin, I encountered the warning below on my machine. The reason is that replacing an old shmem folio with a new one causes mem_cgroup_migrate() to clear the old folio's memcg data. As a result, the old folio cannot get the correct memcg's lruvec needed to remove itself from the LRU list when it is being freed. This could lead to possible serious problems, such as LRU list crashes due to holding the wrong LRU lock, and incorrect LRU statistics. To fix this issue, we can fallback to use the mem_cgroup_replace_folio() to replace the old shmem folio. [ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960 [ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) [ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 [ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 5241.100338] ------------[ cut here ]------------ [ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 [...] [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 [ 5241.100376] sp : ffff80008b38b930 [...] [ 5241.100398] Call trace: [ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100401] __page_cache_release+0x90/0x300 [ 5241.100404] __folio_put+0x50/0x108 [ 5241.100406] shmem_replace_folio+0x1b4/0x240 [ 5241.100409] shmem_swapin_folio+0x314/0x528 [ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930 [ 5241.100412] shmem_fault+0x74/0x160 [ 5241.100414] __do_fault+0x40/0x218 [ 5241.100417] do_shared_fault+0x34/0x1b0 [ 5241.100419] do_fault+0x40/0x168 [ 5241.100420] handle_pte_fault+0x80/0x228 [ 5241.100422] __handle_mm_fault+0x1c4/0x440 [ 5241.100424] handle_mm_fault+0x60/0x1f0 [ 5241.100426] do_page_fault+0x120/0x488 [ 5241.100429] do_translation_fault+0x4c/0x68 [ 5241.100431] do_mem_abort+0x48/0xa0 [ 5241.100434] el0_da+0x38/0xc0 [ 5241.100436] el0t_64_sync_handler+0x68/0xc0 [ 5241.100437] el0t_64_sync+0x14c/0x150 [ 5241.100439] ---[ end trace 0000000000000000 ]--- [baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew] Link: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba.com • https://git.kernel.org/stable/c/85ce2c517ade0d51b7ad95f2e88be9bbe294379a https://git.kernel.org/stable/c/8c6c3719ebb7913f8a665d11816d2e38b0eadbab https://git.kernel.org/stable/c/9094b4a1c76cfe84b906cc152bab34d4ba26fa5c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40948 – mm/page_table_check: fix crash on ZONE_DEVICE
https://notcve.org/view.php?id=CVE-2024-40948
In the Linux kernel, the following vulnerability has been resolved: mm/page_table_check: fix crash on ZONE_DEVICE Not all pages may apply to pgtable check. One example is ZONE_DEVICE pages: they map PFNs directly, and they don't allocate page_ext at all even if there's struct page around. One may reference devm_memremap_pages(). When both ZONE_DEVICE and page-table-check enabled, then try to map some dax memories, one can trigger kernel bug constantly now when the kernel was trying to inject some pfn maps on the dax device: kernel BUG at mm/page_table_check.c:55! While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page fault resolutions, skip all the checks if page_ext doesn't even exist in pgtable checker, which applies to ZONE_DEVICE but maybe more. • https://git.kernel.org/stable/c/df4e817b710809425d899340dbfa8504a3ca4ba5 https://git.kernel.org/stable/c/51897f99351fff7b57f4f141940fa93b4e90fd2b https://git.kernel.org/stable/c/84d3549d54f5ff9fa3281257be3019386f51d1a0 https://git.kernel.org/stable/c/dec2382247860d2134c8d41e103e26460c099629 https://git.kernel.org/stable/c/8bb592c2eca8fd2bc06db7d80b38da18da4a2f43 •