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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40947 – ima: Avoid blocking in RCU read-side critical section
https://notcve.org/view.php?id=CVE-2024-40947
In the Linux kernel, the following vulnerability has been resolved: ima: Avoid blocking in RCU read-side critical section A panic happens in ima_match_policy: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? • https://git.kernel.org/stable/c/c4b035b1f036ddd53fbfced49046e586c5ad8a3e https://git.kernel.org/stable/c/2d4bc60693c4206c64723e94ae5f7a04c0b8f18f https://git.kernel.org/stable/c/8008f1691c15f353f5a53dc5d450b8262cb57421 https://git.kernel.org/stable/c/c7423dbdbc9ecef7fff5239d144cad4b9887f4de https://git.kernel.org/stable/c/38d48fd224036717fcb3437e7af1314f6ebcd2d0 https://git.kernel.org/stable/c/69c60b2a2dbb4887739d3a13297cc0dae3793f35 https://git.kernel.org/stable/c/a6176a802c4bfb83bf7524591aa75f44a639a853 https://git.kernel.org/stable/c/a38e02265c681b51997a264aaf743095e •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40945 – iommu: Return right value in iommu_sva_bind_device()
https://notcve.org/view.php?id=CVE-2024-40945
In the Linux kernel, the following vulnerability has been resolved: iommu: Return right value in iommu_sva_bind_device() iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all. • https://git.kernel.org/stable/c/26b25a2b98e45aeb40eedcedc586ad5034cbd984 https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8 https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998 https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6 https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40944 – x86/kexec: Fix bug with call depth tracking
https://notcve.org/view.php?id=CVE-2024-40944
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Fix bug with call depth tracking The call to cc_platform_has() triggers a fault and system crash if call depth tracking is active because the GS segment has been reset by load_segments() and GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate. Call cc_platform_has() earlier in the function when GS is still valid. [ bp: Massage. ] • https://git.kernel.org/stable/c/5d8213864ade86b48fc492584ea86d65a62f892e https://git.kernel.org/stable/c/d91ddd05082691e69b30744825d18ae799293258 https://git.kernel.org/stable/c/2cfb464669b645a9b98478b74f2bcea9860dcff1 https://git.kernel.org/stable/c/93c1800b3799f17375989b0daf76497dd3e80922 •