CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46787 – userfaultfd: fix checks for huge PMDs
https://notcve.org/view.php?id=CVE-2024-46787
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels. • https://git.kernel.org/stable/c/c1a4de99fada21e2e9251e52cbb51eff5aadc757 https://git.kernel.org/stable/c/3c6b4bcf37845c9359aed926324bed66bdd2448d https://git.kernel.org/stable/c/98cc18b1b71e23fe81a5194ed432b20c2d81a01a https://git.kernel.org/stable/c/71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46781 – nilfs2: fix missing cleanup on rollforward recovery error
https://notcve.org/view.php?id=CVE-2024-46781
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix missing cleanup on rollforward recovery error In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug. It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed. Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts. • https://git.kernel.org/stable/c/0f3e1c7f23f8a6f8224fa1d275381f6d9279ad4b https://git.kernel.org/stable/c/35a9a7a7d94662146396199b0cfd95f9517cdd14 https://git.kernel.org/stable/c/da02f9eb333333b2e4f25d2a14967cff785ac82e https://git.kernel.org/stable/c/07e4dc2fe000ab008bcfe90be4324ef56b5b4355 https://git.kernel.org/stable/c/8e2d1e9d93c4ec51354229361ac3373058529ec4 https://git.kernel.org/stable/c/ca92c4bff2833cb30d493b935168d6cccd5c805d https://git.kernel.org/stable/c/9d8c3a585d564d776ee60d4aabec59b404be7403 https://git.kernel.org/stable/c/1cf1f7e8cd47244fa947d357ef1f642d9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46780 – nilfs2: protect references to superblock parameters exposed in sysfs
https://notcve.org/view.php?id=CVE-2024-46780
In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect references to superblock parameters exposed in sysfs The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem". Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it. • https://git.kernel.org/stable/c/da7141fb78db915680616e15677539fc8140cf53 https://git.kernel.org/stable/c/b90beafac05931cbfcb6b1bd4f67c1923f47040e https://git.kernel.org/stable/c/ba97ba173f9625d5f34a986088979eae8b80d38e https://git.kernel.org/stable/c/157c0d94b4c40887329418c70ef4edd1a8d6b4ed https://git.kernel.org/stable/c/b14e7260bb691d7f563f61da07d61e3c8b59a614 https://git.kernel.org/stable/c/19cfeba0e4b8eda51484fcf8cf7d150418e1d880 https://git.kernel.org/stable/c/8c6e43b3d5f109cf9c61bc188fcc8175404e924f https://git.kernel.org/stable/c/962562d4c70c5cdeb4e955d63ff2017c4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46778 – drm/amd/display: Check UnboundedRequestEnabled's value
https://notcve.org/view.php?id=CVE-2024-46778
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check UnboundedRequestEnabled's value CalculateSwathAndDETConfiguration_params_st's UnboundedRequestEnabled is a pointer (i.e. dml_bool_t *UnboundedRequestEnabled), and thus if (p->UnboundedRequestEnabled) checks its address, not bool value. This fixes 1 REVERSE_INULL issue reported by Coverity. • https://git.kernel.org/stable/c/4e2b49a85e7974d21364798c5d4aa8070aa864d9 https://git.kernel.org/stable/c/a7b38c7852093385d0605aa3c8a2efd6edd1edfd •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46777 – udf: Avoid excessive partition lengths
https://notcve.org/view.php?id=CVE-2024-46777
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap. • https://git.kernel.org/stable/c/c0c23130d38e8bc28e9ef581443de9b1fc749966 https://git.kernel.org/stable/c/1497a4484cdb2cf6c37960d788fb6ba67567bdb7 https://git.kernel.org/stable/c/551966371e17912564bc387fbeb2ac13077c3db1 https://git.kernel.org/stable/c/2ddf831451357c6da4b64645eb797c93c1c054d1 https://git.kernel.org/stable/c/0173999123082280cf904bd640015951f194a294 https://git.kernel.org/stable/c/a56330761950cb83de1dfb348479f20c56c95f90 https://git.kernel.org/stable/c/925fd8ee80d5348a5e965548e5484d164d19221d https://git.kernel.org/stable/c/ebbe26fd54a9621994bc16b14f2ba8f84 •