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: 2EXPL: 0CVE-2024-50068 – mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets()
https://notcve.org/view.php?id=CVE-2024-50068
In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. unreferenced object 0xffffff80c2a8db80 (size 96): comm "kunit_try_catch", pid 187, jiffies 4294894363 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 • https://git.kernel.org/stable/c/b8ee5575f763c239902f8523d82103a45c153b29 https://git.kernel.org/stable/c/05d43455f6bffa6abc7b937ca58be00452e6973f https://git.kernel.org/stable/c/2d6a1c835685de3b0c8e8dc871f60f4ef92ab01a •
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') •