{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-38102", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-38102" ], "published": "2025-07-03T08:36:23Z", "summary": "VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context->notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update &context->notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context->notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.142", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-38102" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/74095bbbb19ca74a0368d857603a2438c88ca86c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/468aec888f838ce5174b96e0cb4396790d6f60ca" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b4209e4b778e4e57d0636e1c9fc07a924dbc6043" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/58a90db70aa6616411e5f69d1982d9b1dd97d774" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6e3af836805ed1d7a699f76ec798626198917aa4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576c36f9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only through `IOCTL_VMCI_SET_NOTIFY` on the `/dev/vmci` character device (`vmci_host_unlocked_ioctl` \u2192 `vmci_host_do_set_notify`), which requires local access to the host system. There is no remote or network-facing path into the VMCI host personality.\nAC:L - The attacker controls both sides of the race \u2014 two threads issuing `SET_NOTIFY` on the same fd, one with a non-zero `notify_uva` and one with zero \u2014 and `vmci_host_do_set_notify` is not serialized by `vmci_host_dev->lock`, so the race can be looped indefinitely. Backing the UVA with a THP widens the window further, since `record_subpages()` in `gup_huge_pmd` publishes the page pointer into `context->notify_page` before the pin is validated.\nPR:L - There is no `capable()`, credential, or privilege check anywhere in `vmci_host_open()`, `vmci_ctx_create()`, or the SET_NOTIFY ioctl path \u2014 only the permissions on `/dev/vmci` gate access, and on VMware Workstation/Player hosts that node must be accessible to unprivileged users because the per-user VMX process opens it to create its VMCI context. A normal local user account is therefore sufficient.\nUI:N - Exploitation is entirely self-contained: the attacker opens `/dev/vmci`, issues `INIT_CONTEXT`, and races two `SET_NOTIFY` ioctls from its own threads. No victim action is required.\nS:U - The corruption occurs in host kernel memory and is exploited by a local host user, staying within the kernel's own security authority. Although VMCI is virtualization-related, this is the host-side personality driven by local ioctls, not a guest-to-host boundary crossing.\nC:H - `vmci_ctx_unset_notify()` calls `put_page()` on a pointer that `get_user_pages_fast()` published into `context->notify_page` before taking (or after rolling back) the reference, producing a refcount underflow that frees a page still mapped by userspace and still in use elsewhere. Once that page is recycled into kernel allocations while the attacker retains a user mapping, arbitrary kernel memory can be read.\nI:H - The same premature free gives the attacker a writable userspace mapping of a page the kernel later reallocates, a direct arbitrary-write primitive; additionally `context->notify` is left dangling into a released page and `ctx_signal_notify()` writes `true` through it at an attacker-chosen page offset when a datagram is queued. Both paths are readily leveraged for control-flow hijacking and privilege escalation.\nA:H - The race reliably trips `WARN_ON` in `try_grab_folio` (as reported by syzkaller) and, in the general case, causes page refcount underflow, double-free, and use-after-free of memory still in use, leading to kernel oops or panic. It can be triggered repeatedly by an unprivileged process." } } }