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 pointe... • 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 ... • 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. ... • 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 p... • 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 m... • 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 ... • 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 re... • https://git.kernel.org/stable/c/26b25a2b98e45aeb40eedcedc586ad5034cbd984 • CWE-393: Return of Wrong Status Code •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40944 – x86/kexec: Fix bug with call depth tracking
https://notcve.org/view.php?id=CVE-2024-40944
12 Jul 2024 — 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. ] In the Linux kernel, the following vulnerability has been resolved: x86/... • https://git.kernel.org/stable/c/5d8213864ade86b48fc492584ea86d65a62f892e •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40943 – ocfs2: fix races between hole punching and AIO+DIO
https://notcve.org/view.php?id=CVE-2024-40943
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix races between hole punching and AIO+DIO After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) wit... • https://git.kernel.org/stable/c/b25801038da5823bba1b5440a57ca68afc51b6bd •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40942 – wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
https://notcve.org/view.php?id=CVE-2024-40942
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: u... • https://git.kernel.org/stable/c/050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e •