CVSS: 5.5EPSS: 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
12 Jul 2024 — 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] Rea... • https://git.kernel.org/stable/c/7e170922f06bf46effa7c57f6035fc463d6edc7e •
CVSS: 7.8EPSS: 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
12 Jul 2024 — 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-afte... • https://git.kernel.org/stable/c/c5dbb89fc2ac013afe67b9e4fcb3743c02b567cd • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 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
12 Jul 2024 — 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 l... • https://git.kernel.org/stable/c/217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40952 – ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
https://notcve.org/view.php?id=CVE-2024-40952
12 Jul 2024 — 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 dere... • https://git.kernel.org/stable/c/8887b94d93224e0ef7e1bc6369640e313b8b12f4 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40951 – ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()
https://notcve.org/view.php?id=CVE-2024-40951
12 Jul 2024 — 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-in... • https://git.kernel.org/stable/c/8887b94d93224e0ef7e1bc6369640e313b8b12f4 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40950 – mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
https://notcve.org/view.php?id=CVE-2024-40950
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios When I did a large folios split test, a WARNING "[ 5059.122759][ T166] Cannot split file folio to non-0 order" was triggered. But the test cases are only for anonmous folios. while mapping_large_folio_support() is only reasonable for page cache folios. In split_huge_page_to_list_to_order(), the folio passed to mapping_large_folio_support() maybe anonmous folio. The f... • https://git.kernel.org/stable/c/c010d47f107f609b9f4d6a103b6dfc53889049e9 •
CVSS: 7.0EPSS: 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
12 Jul 2024 — 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 proble... • https://git.kernel.org/stable/c/85ce2c517ade0d51b7ad95f2e88be9bbe294379a •
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
12 Jul 2024 — 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 o... • https://git.kernel.org/stable/c/df4e817b710809425d899340dbfa8504a3ca4ba5 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40947 – ima: Avoid blocking in RCU read-side critical section
https://notcve.org/view.php?id=CVE-2024-40947
12 Jul 2024 — 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 ... • https://git.kernel.org/stable/c/c4b035b1f036ddd53fbfced49046e586c5ad8a3e •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40945 – iommu: Return right value in iommu_sva_bind_device()
https://notcve.org/view.php?id=CVE-2024-40945
12 Jul 2024 — 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 retur... • https://git.kernel.org/stable/c/26b25a2b98e45aeb40eedcedc586ad5034cbd984 • CWE-393: Return of Wrong Status Code •