CVE-2026-80724 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
ptp: vmclock: prevent read-only mappings from becoming writable
vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only.
Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified within the Linux kernel's ptp vmclock subsystem represents a critical failure in memory protection enforcement, specifically concerning the handling of shared pages between guest virtual machines and the host hypervisor. The core technical flaw resides in the implementation of the vmclock_miscdev_mmap function, which is responsible for mapping the shared vmclock ABI page into user space. While this function correctly rejects direct attempts by userspace to map the page with write permissions by returning an -EROFS error code, it fails to clear the VM_MAYWRITE flag within the virtual memory area (VMA) structure when establishing a read-only mapping. This oversight creates a significant security gap because the presence of the VM_MAYWRITE flag signals that the memory region is eligible for permission changes via system calls such as mprotect(). Consequently, an attacker operating within a guest environment can initially map the vmclock page with read-only access and subsequently invoke mprotect to upgrade the protection flags to include write permissions. This sequence effectively bypasses the initial restriction imposed by the kernel driver, allowing the guest process to gain unauthorized write access to memory regions that are strictly intended for host-side updates only.
The operational impact of this vulnerability is severe due to the nature of the data contained within the vmclock ABI page. These pages hold critical timekeeping information including sequence counters, UTC time values, and TSC offsets, which are written by the hypervisor to ensure accurate clock synchronization across virtual machines. When a guest can corrupt these host-written fields, it disrupts the fundamental timing mechanisms relied upon by both the guest operating system and potentially other guests sharing the same physical hardware resources through the hypervisor. This corruption can lead to unpredictable behavior in time-sensitive applications running within the affected VM, such as financial trading systems or real-time control software that depend on precise timestamps. Furthermore, because the vmclock data is shared across multiple virtual machines managed by the host, an attacker could potentially manipulate timing information in a way that affects system-wide consistency or attempts to escalate privileges by exploiting race conditions related to time-based checks within kernel modules or security mechanisms inside the guest OS.
From a classification perspective, this vulnerability aligns with CWE-276, which covers Incorrect Default Permissions, as the default state of the memory mapping incorrectly allows for future write access despite an initial read-only intent. It also relates closely to CWE-119, specifically Improper Restriction of Operations within the Bounds of a Memory Buffer, since the attacker is performing unauthorized write operations on a buffer they do not own or control. In terms of attack vectors and techniques, this flaw facilitates privilege escalation from user space to kernel-level integrity compromise without requiring local code execution vulnerabilities in other components. It maps directly to MITRE ATT&CK technique T1055.009, Process Injection via Memory Mapping, although the primary goal here is data corruption rather than code injection. The attack pattern resembles techniques seen in CVE-2026-68445 and CVE-2024-53071 involving drm/vc4 and drm/panthor drivers respectively, where similar failures to restrict memory write permissions led to potential host or kernel data corruption.
To mitigate this vulnerability, the Linux kernel developers have implemented a fix that explicitly clears the VM_MAYWRITE flag on the read-only path within vmclock_miscdev_mmap(). This ensures that once a mapping is established as read-only, it cannot be upgraded to writable via mprotect(), thereby enforcing the intended security boundary between guest and host memory spaces. System administrators should apply kernel updates containing this patch immediately to restore proper access controls for virtualized timekeeping services. Additionally, organizations relying on virtualization platforms with ptp vmclock enabled should verify that their hypervisor software is updated in conjunction with the guest kernels to ensure end-to-end protection against timing manipulation attacks. Regular auditing of memory mapping permissions and adherence to least-privilege principles when configuring shared memory regions are recommended best practices to prevent similar issues in other kernel subsystems.