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: 5.5EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-40948 https://bugzilla.redhat.com/show_bug.cgi?id=2297532 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
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: 4.4EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-40945 • CWE-393: Return of Wrong Status Code •