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: 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 •