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-40950 – mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
https://notcve.org/view.php?id=CVE-2024-40950
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 folio_test_anon() check is missing. So the split of the anonmous THP is failed. • https://git.kernel.org/stable/c/c010d47f107f609b9f4d6a103b6dfc53889049e9 https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a •
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 •