CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35877 – x86/mm/pat: fix VM_PAT handling in COW mappings
https://notcve.org/view.php?id=CVE-2024-35877
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # . • https://git.kernel.org/stable/c/5899329b19100c0b82dc78e9b21ed8b920c9ffb3 https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173 https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4 https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd3 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35875 – x86/coco: Require seeding RNG with RDRAND on CoCo systems
https://notcve.org/view.php?id=CVE-2024-35875
In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. • https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374 https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5 https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584 https://access.redhat.com/security/cve/CVE-2024-35875 https://bugzilla.redhat.com/show_bug.cgi?id=2281727 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35872 – mm/secretmem: fix GUP-fast succeeding on secretmem folios
https://notcve.org/view.php?id=CVE-2024-35872
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/secretmem: corrige el éxito rápido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. • https://git.kernel.org/stable/c/1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48 https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8 https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5 https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35871 – riscv: process: Fix kernel gp leakage
https://notcve.org/view.php?id=CVE-2024-35871
In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. • https://git.kernel.org/stable/c/7db91e57a0acde126a162ababfb1e0ab190130cb https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5 https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84 https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4 https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9 https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.9EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35870 – smb: client: fix UAF in smb2_reconnect_server()
https://notcve.org/view.php?id=CVE-2024-35870
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? • https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0 https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5 https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa https://access.redhat.com/security/cve/CVE-2024-35870 https://bugzilla.redhat.com/show_bug.cgi?id=2281740 • CWE-416: Use After Free •