CVE-2026-64514

What it actually does

This is a local Linux kernel denial-of-service flaw in the userfaultfd memory-fault handling path. The kernel re-checks whether a write-protected userfaultfd page fault should continue waiting by reading a page table entry without the page-table lock. It then applies present-page write-bit checks to entries that may actually be swap or migration entries. Because those non-present entries encode different data in the same bit positions, the kernel can make an incorrect wait decision. In the worst case, a faulting thread is left asleep waiting for a UFFDIO_WAKE event that will not occur, causing the affected process or workload to hang.

Why it matters to the business

An attacker who can run local code on a vulnerable Linux system, including in some container or multi-user hosting scenarios where userfaultfd is available, may be able to hang targeted processes or degrade service availability. The risk is primarily operational disruption rather than data theft or remote compromise. EPSS is currently low and the issue is not listed in CISA KEV or ransomware-tracked exploitation, but kernel availability bugs should still be prioritized on shared compute, container platforms, CI runners, database hosts, and other systems that allow untrusted or semi-trusted local code execution.

How an attack unfolds

Exploitation requires local ability to invoke or interact with userfaultfd. An attacker prepares a memory region registered with userfaultfd, typically using write-protection fault handling, and then attempts to create timing conditions where the page table entry transitions to a non-present state such as swap-out or migration while the kernel is performing its lockless must-wait re-check. If the non-present entry's offset bits are misinterpreted as present-PTE writability bits, the kernel may decide that the faulting thread must keep waiting. Because the page is no longer in the same userfaultfd context and the expected userspace wake-up may never be issued, the thread can remain blocked. Repeating this against important worker processes or using it to consume service capacity can produce a denial of service.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the userfaultfd fix for this issue. Where immediate patching is not possible, reduce exposure by disabling or restricting unprivileged userfaultfd where supported, for example by setting vm.unprivileged_userfaultfd=0, and by using seccomp, container runtime profiles, or sandbox policy to block the userfaultfd syscall for workloads that do not require it. Limit local shell access, untrusted container execution, and workload co-tenancy on vulnerable kernels. If userfaultfd is required for legitimate software such as live migration, checkpoint/restore, or specialized runtimes, test mitigations carefully before enforcing them globally.

How to confirm the fix worked

Confirm the running kernel version includes the vendor patch for the userfaultfd must-wait PTE-present check. Validate both the installed package version and the active booted kernel, because kernel updates often require a reboot. On Linux, compare uname -r with the distribution advisory fixed version, verify package manager history, and confirm no older vulnerable kernels remain selected as the default boot entry. Check whether unprivileged userfaultfd is disabled by reading /proc/sys/vm/unprivileged_userfaultfd where available. For sandboxed environments, confirm seccomp or container profiles deny the userfaultfd syscall unless explicitly required. Functional validation should include regression testing of workloads that legitimately rely on userfaultfd, such as live migration or memory-management tooling.

Typical attack path

1. Gain local code execution on a vulnerable Linux system or inside a workload where the userfaultfd syscall is permitted.
2. Create or access a process that uses userfaultfd, especially write-protection fault handling.
3. Register a memory range with userfaultfd and arrange for controlled page faults on that range.
4. Apply memory pressure or trigger page migration/swap behavior so the page table entry becomes non-present during the relevant fault-handling window.
5. Race the userfaultfd must-wait re-check so the kernel evaluates write status on a swap or migration entry instead of a present PTE.
6. Cause the target thread to sleep waiting for a userfaultfd wake-up that may never arrive.
7. Repeat or target service-critical threads to cause process hangs, degraded throughput, or service outage.

How to detect it

Retrospective detection is difficult because this flaw does not necessarily create a distinctive security log event. Focus on behavioral evidence: kernel logs showing hung tasks or blocked processes, audit records showing use of the userfaultfd syscall by unexpected users or containers, service logs showing unexplained worker stalls, and telemetry indicating memory pressure, swap activity, or page migration near the time of the outage. Useful sources include auditd syscall logs, eBPF/seccomp telemetry, container runtime syscall-deny/allow logs, kernel ring buffer output from dmesg or journald, process stack captures from hung processes, /proc file descriptor listings showing userfaultfd handles, and workload health metrics. Investigate processes with file descriptors referencing anon_inode:[userfaultfd], threads stuck in kernel fault-handling paths, or repeated service hangs without crashes. Absence of logs does not rule out exploitation; the most reliable determination is correlation of vulnerable kernel exposure, unexpected userfaultfd use, and unexplained blocked-task symptoms.

• anon_inode:[userfaultfd]
• userfaultfd
• UFFDIO_WAKE
• UFFDIO_WRITEPROTECT
• blocked for more than 120 seconds
• hung_task_timeout_secs
• INFO: task
• syscall=userfaultfd
• comm="userfaultfd"
• /proc/sys/vm/unprivileged_userfaultfd
• vm.unprivileged_userfaultfd
• userfaultfd_must_wait
• userfaultfd_huge_must_wait

What your security team should do

• Prioritize kernel patching for multi-tenant Linux systems, container hosts, CI/build runners, developer workstations with untrusted code execution, and systems running workloads that expose userfaultfd to non-root users.
• Inventory systems where userfaultfd is enabled and where /proc/sys/vm/unprivileged_userfaultfd permits unprivileged use.
• Temporarily set vm.unprivileged_userfaultfd=0 on vulnerable systems if compatible with operational requirements.
• Add or tighten seccomp/container policies to deny the userfaultfd syscall for workloads that do not require it.
• Monitor for unexpected use of userfaultfd by untrusted users, containers, or newly deployed binaries.
• Investigate unexplained process hangs, blocked tasks, or service degradation on vulnerable kernels, especially when correlated with memory pressure, swap activity, migration, or userfaultfd activity.
• After patching, reboot into the fixed kernel and remove or deprioritize vulnerable kernels from boot configurations where feasible.