Look up another CVE · open CVE-2026-80724 in the interactive tracker
CVE-2026-80724
ptp: vmclock: prevent read-only mappings from becoming writable
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem drivers/ptp. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80724 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.12-1 | Update the kernel and reboot. Fixed in 7.1.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.12-1 | Update the kernel and reboot. Fixed in 7.1.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/ptp/ptp_vmclock.c
- What this is
- PTP VMCLOCK SUPPORTMAINTAINERS section matched on drivers/ptp/ptp_vmclock.c · netdev@vger.kernel.org · Maintained
- Kernel module
- ptp_vmclock
Check it on the machine
grep -w CONFIG_PTP_1588_CLOCK_VMCLOCK /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ptp_vmclockPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidBnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- B
- built in on some, a module on others, absent on the rest
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_PTP_1588_CLOCK_VMCLOCK
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/ptp
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.13 | 6.18.47 | 5b4f2bec7bea |
| 6.13 | 6.18.50 | 3f5677d2f817 |
| 6.13 | 7.1.11 | 2496e1418271 |
| 6.13 | 7.2.1 | 2e596e7814ba |
| 6.13 | 7.2.4 | 0ce59c4148ec |
| 6.13 | 7.3 | a5edadbae57e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires local syscalls to open /dev/vmclock0, mmap the shared ABI page read-only, mprotect it writable, and write host-authoritative fields; there is no network, Bluetooth, or physical-device path to vmclock_miscdev_mmap().
- AC:LAttack complexity, low
- Any process that can open the misc device can reliably mmap(PROT_READ), mprotect(PROT_WRITE), and corrupt the page without races, special memory layout, or timing; VM_MAYWRITE left set is the sole missing check and mprotect honors it per mm/mprotect.c.
- PR:LPrivileges required, low
- vmclock_miscdev_open() performs no capability checks; AWS ClockBound documents chmod a+r on /dev/vmclock0 for unprivileged latency-sensitive apps on EC2/Amazon Linux, so a normal tenant user on affected cloud VMs can reach the bug without root or user-namespace admin caps.
- UI:NUser interaction, none
- The attacker process performs the full open/mmap/mprotect/write sequence itself; no victim mount, click, or other user action is required beyond the attacker already having local shell access.
- S:CScope, changed
- The vmclock ABI page is hypervisor-written shared memory whose seq_count, UTC time, and TSC offset must stay guest-read-only; mprotect bypass lets a guest user corrupt that host-authoritative data, crossing the guest/hypervisor trust boundary rather than staying within guest-kernel scope alone.
- C:HConfidentiality impact, high
- Unauthorized writes let an attacker race seq_count updates and corrupt in-flight host-populated fields, yielding torn reads of timekeeping data to other guest consumers and potentially exposing transient host-written values that read-only mmap alone would not reliably observe.
- I:HIntegrity impact, high
- After mprotect, the attacker gains arbitrary modification of host-written vmclock_abi fields (seq_count, disruption_marker, counter_value, time_sec, flags), breaking integrity of authoritative timekeeping and migration/disruption signaling relied on by guest kernel PTP and userspace ClockBound consumers.
- A:HAvailability impact, high
- Corrupting seq_count, clock_status, or disruption/vm_generation markers can force ETIMEDOUT/-EINVAL in vmclock_get_crosststamp, trigger false migration/disruption handling, and cause latency-sensitive services to withdraw or fail, producing severe availability loss on affected cloud VMs.