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: 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: 4EXPL: 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/755fe68cd4b59e1d2a2dd3286177fd4404f57fed 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 •
CVSS: 8.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35869 – smb: client: guarantee refcounted children from parent session
https://notcve.org/view.php?id=CVE-2024-35869
In the Linux kernel, the following vulnerability has been resolved: smb: client: guarantee refcounted children from parent session Avoid potential use-after-free bugs when walking DFS referrals, mounting and performing DFS failover by ensuring that all children from parent @tcon->ses are also refcounted. They're all needed across the entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at it, too. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: garantiza que los hijos recontados desde la sesión principal Evite posibles errores de use after free al recorrer referencias DFS, montar y realizar la conmutación por error de DFS asegurándose de que todos los hijos del padre @tcon- >ses también se cuentan nuevamente. Todos son necesarios en todo el montaje DFS. • https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79 https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a https://access.redhat.com/security/cve/CVE-2024-35869 https://bugzilla.redhat.com/show_bug.cgi?id=2281742 • CWE-416: Use After Free •