CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42233 – filemap: replace pte_offset_map() with pte_offset_map_nolock()
https://notcve.org/view.php?id=CVE-2024-42233
In the Linux kernel, the following vulnerability has been resolved: filemap: replace pte_offset_map() with pte_offset_map_nolock() The vmf->ptl in filemap_fault_recheck_pte_none() is still set from handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table may be racily changed and vmf->ptl maybe fails to protect the actual page table. Fix this by replacing pte_offset_map() with pte_offset_map_nolock(). As David said, the PTL pointer might be stale so if we continue to use it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()") might reappear. • https://git.kernel.org/stable/c/58f327f2ce80f9c7b4a70e9cf017ae8810d44a20 https://git.kernel.org/stable/c/6a6c2aec1a89506595801b4cf7e8eef035f33748 https://git.kernel.org/stable/c/24be02a42181f0707be0498045c4c4b13273b16d •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42232 – libceph: fix race between delayed_work() and ceph_monc_stop()
https://notcve.org/view.php?id=CVE-2024-42232
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed • https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7 https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ec •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42231 – btrfs: zoned: fix calc_available_free_space() for zoned mode
https://notcve.org/view.php?id=CVE-2024-42231
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix calc_available_free_space() for zoned mode calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places. First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo->chunk_size) as it is. Second, the result "avail" may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process. This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. • https://git.kernel.org/stable/c/cb6cbab79055ca207ad88bc54226b48ececdcef0 https://git.kernel.org/stable/c/8548903b1999bba02a2b894ad750ab8eb1f40307 https://git.kernel.org/stable/c/64d2c847ba380e07b9072d65a50aa6469d2aa43f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42230 – powerpc/pseries: Fix scv instruction crash with kexec
https://notcve.org/view.php?id=CVE-2024-42230
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. • https://git.kernel.org/stable/c/7fa95f9adaee7e5cbb195d3359741120829e488b https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5 https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3 https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42229 – crypto: aead,cipher - zeroize key buffer after use
https://notcve.org/view.php?id=CVE-2024-42229
In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. • https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133 https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534 https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210 •