CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50072 – x86/bugs: Use code segment selector for VERW operand
https://notcve.org/view.php?id=CVE-2024-50072
In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. • https://git.kernel.org/stable/c/50f021f0b985629accf10481a6e89af8b9700583 https://git.kernel.org/stable/c/d54de9f2a127090f2017184e8257795b487d5312 https://git.kernel.org/stable/c/2e3087505ddb8ba2d3d4c81306cca11e868fcdb9 https://git.kernel.org/stable/c/ca13d8cd8dac25558da4ee8df4dc70e8e7f9d762 https://git.kernel.org/stable/c/a0e2dab44d22b913b4c228c8b52b2a104434b0b3 https://git.kernel.org/stable/c/51eca9f1fd047b500137d021f882d93f03280118 https://git.kernel.org/stable/c/bfd1d223d80cb29a210caa1bd5e21f0816d58f02 https://git.kernel.org/stable/c/ada431c6c31a2c8c37991c46089af5caa •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50070 – pinctrl: stm32: check devm_kasprintf() returned value
https://notcve.org/view.php?id=CVE-2024-50070
In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review. • https://git.kernel.org/stable/c/32c170ff15b044579b1f8b8cdabf543406dde9da https://git.kernel.org/stable/c/3b36bb1fca2b87f6292ca2a8593f297c5e9fab41 https://git.kernel.org/stable/c/1f266957ae1207b0717c2d69096bc70654ae9fcb https://git.kernel.org/stable/c/b0f0e3f0552a566def55c844b0d44250c58e4df6 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50069 – pinctrl: apple: check devm_kasprintf() returned value
https://notcve.org/view.php?id=CVE-2024-50069
In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review. • https://git.kernel.org/stable/c/a0f160ffcb83de6a04fa75f9e7bdfe969f2863f7 https://git.kernel.org/stable/c/0a4d4dbef622ac8796a6665e0080da2685f9220a https://git.kernel.org/stable/c/fad940e2dd789155f99ecafa71a7baf6f96530bc https://git.kernel.org/stable/c/4d2296fb7c80fdc9925d29a8e85d617cad08731a https://git.kernel.org/stable/c/665a58fe663ac7a9ea618dc0b29881649324b116 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50067 – uprobe: avoid out-of-bounds memory access of fetching args
https://notcve.org/view.php?id=CVE-2024-50067
In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c` 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? • https://git.kernel.org/stable/c/dcad1a204f72624796ae83359403898d10393b9c https://git.kernel.org/stable/c/0dc3ad9ad2188da7f090b3dbe4d2fcd9ae8ae64f https://git.kernel.org/stable/c/9e5f93788c9dd4309e75a56860a1ac44a8e117b9 https://git.kernel.org/stable/c/537ad4a431f6dddbf15d40d19f24bb9ee12b55cb https://git.kernel.org/stable/c/373b9338c9722a368925d83bc622c596896b328e •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50066 – mm/mremap: fix move_normal_pmd/retract_page_tables race
https://notcve.org/view.php?id=CVE-2024-50066
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. • https://git.kernel.org/stable/c/1d65b771bc08cd054cf6d3766a72e113dc46d62f https://git.kernel.org/stable/c/17396e32f975130b3e6251f024c8807d192e4c3e https://git.kernel.org/stable/c/1552ce9ce8af47c0fe911682e5e1855e25851ca9 https://git.kernel.org/stable/c/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa https://project-zero.issues.chromium.org/issues/371047675 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •