USN-8728-1: Ubuntu Linux Kernel (GCP) Privilege Escalation — CVE-2025-10263 and CVE-2025-54518 Remediation Guide

Canonical has published USN-8728-1, a security update for the Linux kernel build targeted at Google Cloud Platform (GCP) instances running Ubuntu. The advisory addresses two processor-level vulnerabilities that permit local privilege escalation — CVE-2025-10263, a translation lookaside buffer (TLB) invalidation race affecting certain Arm processors, and CVE-2025-54518, an operation cache isolation failure affecting AMD Zen 2 processors — along with several additional kernel security issues rolled into the same update.

If you operate Ubuntu workloads on GCP — particularly multi-tenant container hosts, shared CI/CD runners, or any instance where untrusted or semi-trusted code executes locally — this is a priority patch. Both flaws are local attack vectors, which means they are not wormable on their own, but they are exactly the class of vulnerability that turns a low-privileged foothold (a compromised container, a malicious dependency in a build pipeline, an attacker with shell access) into full root control of the host. In cloud environments, host compromise frequently means lateral movement into the metadata service, attached service accounts, and neighboring workloads.

Technical Analysis

Affected Platforms

• Product: Linux kernel, GCP-optimized build (linux-gcp), distributed via Ubuntu Security Notice USN-8728-1
• Scope: Ubuntu instances running the GCP kernel flavor on Google Cloud Platform
• Hardware dependency:
  • CVE-2025-10263 — affects systems running on certain Arm processors
  • CVE-2025-54518 — affects systems running on AMD Zen 2 CPUs (EPYC Rome-family silicon is common in cloud fleets)
• Additional fixes: The update also carries several other unspecified kernel security fixes, per the advisory.

Canonical did not publish CVSS vectors in the notice text; both issues are local privilege escalation / memory protection bypass class flaws. Treat them as high-severity on any multi-user or multi-tenant host, and medium-high on single-tenant hosts.

CVE-2025-10263 — Arm TLB Invalidation Race (Write-After-Permission-Revocation)

The flaw is a memory-ordering defect in how some Arm processors handle broadcast TLB invalidation. The sequence that matters defensively:

1. The kernel revokes write permission on a memory mapping and issues a broadcast TLB invalidate to flush the now-invalid translation across cores.
2. Affected Arm cores can complete the invalidation before memory writes made through the old translation are globally observed.
3. A local attacker racing this window can land a write to memory after the kernel believes permission has been revoked.

The practical consequence: memory protection guarantees the kernel relies on are violated. An attacker-controlled userspace process can write into memory it should no longer be able to touch — a classic primitive for corrupting kernel-adjacent data or credentials and escalating to root. This is the same architectural family of defect as earlier TLB/invalidation ordering issues: the fix is in the kernel's invalidation sequencing and barrier handling, not in firmware alone.

Exploitation requirements: local code execution on an affected Arm-based instance, plus the ability to win a tight timing race. Race-condition exploits of this type are routinely made reliable with retry loops — defenders should not discount them as "theoretical."

CVE-2025-54518 — AMD Zen 2 Operation Cache Isolation Failure

On AMD Zen 2 processors, the operation cache (op cache) — a microarchitectural structure that caches decoded instruction sequences — did not properly isolate shared resources between privilege contexts. A local attacker can exploit this to corrupt instructions that will execute at a higher privilege level, directly yielding unauthorized privilege gain.

Instruction corruption at ring 0 is about as bad as a local escalation primitive gets: rather than abusing a kernel logic bug, the attacker is tampering with the actual instruction stream the CPU executes with elevated privilege. Because the root cause is silicon behavior, mitigation involves kernel-level changes (cache management/isolation handling), and operators should verify whether AMD microcode updates are additionally required for their fleet — check with your cloud provider and Canonical's advisory chain.

Exploitation Status

As of this writing:

• No public proof-of-concept exploit has been observed for either CVE.
• Neither CVE-2025-10263 nor CVE-2025-54518 appears in the CISA Known Exploited Vulnerabilities (KEV) catalog.
• No confirmed in-the-wild exploitation has been reported.

That said, local privilege escalation bugs in the Linux kernel are among the most consistently weaponized vulnerability classes — they are the second stage in nearly every container-escape and post-foothold chain. The absence of a public PoC is a window, not a comfort.

Detection & Response

Because these are local privilege escalation primitives, detection strategy centers on two things: (1) identifying hosts still running a vulnerable kernel, and (2) alerting on the behavioral aftermath of a successful escalation — a non-root process transitioning to root execution, or unexpected access to kernel debugging and performance subsystems that local exploit tooling commonly abuses.

Sigma Rules

---
title: Unexpected Privilege Transition to Root via Auditd Execve
id: 3f9a1c72-8b4d-4e6a-b2c1-7d5e9f0a2b34
status: experimental
description: Detects execve events where a process running as a non-root user executes with effective UID 0, consistent with successful local privilege escalation such as exploitation of kernel memory-corruption flaws (e.g., USN-8728-1 Arm TLB / AMD op cache issues).
references:
  - https://ubuntu.com/security/notices/USN-8728-1
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: auditd
  product: linux
detection:
  selection:
    type: 'EXECVE'
    euid: 0
  filter_known_privileged:
    uid:
      - 0
    auuid:
      - 0
      - 4294967295
  condition: selection and not filter_known_privileged
falsepositives:
  - Legitimate sudo/su usage by administrators (tune by auuid or parent process)
  - Package management and configuration management agents
level: high
---
title: Suspicious Access to Kernel Debug and Perf Subsystems
id: 8c2e5d91-4a7f-4b38-9e6d-1f3c8a5b7d02
status: experimental
description: Detects non-privileged processes interacting with kernel debugfs, perf, or kprobe interfaces frequently leveraged by local kernel exploit tooling for privilege escalation primitives.
references:
  - https://ubuntu.com/security/notices/USN-8728-1
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.discovery
logsource:
  category: process_creation
  product: linux
detection:
  selection_paths:
    CommandLine|contains:
      - '/sys/kernel/debug'
      - '/sys/kernel/tracing'
      - 'perf_event_open'
      - '/proc/kallsyms'
  selection_tools:
    Image|endswith:
      - '/perf'
      - '/bpftrace'
      - '/kprobe'
  filter_root:
    User|contains: 'root'
  condition: (selection_paths or selection_tools) and not filter_root
falsepositives:
  - Performance engineering and SRE diagnostics (tune by service account)
  - Observability agents using eBPF — allowlist known agent paths
level: medium

KQL — Microsoft Sentinel (Syslog / CEF ingestion)

This query hunts for the post-exploitation signature of a local escalation: shells or sensitive command execution where the session context indicates a non-system user, plus hosts that have not yet rebooted into the patched kernel.

// Hunt 1: Privilege escalation aftermath — root-executed shells from user sessions
Syslog
| where TimeGenerated > ago(7d)
| where Facility =~ "authpriv" or ProcessName in~ ("sudo", "su", "auditd")
| where SyslogMessage has_any ("euid=0", "uid=0", "session opened for user root")
| where SyslogMessage !has_any ("cron", "CRON", "systemd", "packagekit")
| summarize Events = count(), Samples = make_list(SyslogMessage, 5) by Computer, ProcessName, bin(TimeGenerated, 1h)
| order by Events desc;

// Hunt 2: Fleet exposure — identify GCP instances reporting an outdated kernel
Heartbeat
| where TimeGenerated > ago(1d)
| summarize arg_max(TimeGenerated, *) by Computer
| project Computer, OSType, OSName = tostring(Computer)
| join kind=inner (
    Syslog
    | where TimeGenerated > ago(1d)
    | where SyslogMessage has "Linux version"
    | summarize KernelString = any(SyslogMessage) by Computer
) on Computer
| project Computer, KernelString, TimeGenerated
| order by Computer asc

Velociraptor VQL

Use this artifact to sweep your Linux estate for vulnerable kernel versions and processes that transitioned to UID 0 from non-root contexts — the forensic residue of a successful escalation.

-- Identify vulnerable kernels and unexpected UID-0 processes on Linux endpoints
SELECT {
    SELECT Name FROM stat(path="/proc/sys/kernel/hostname")
} AS Hostname,
{
    SELECT Data FROM read_file(filename="/proc/version")
} AS KernelVersion,
Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Username =~ "root"
  AND Exe !~ "(systemd|sshd|cron|salt|chef|puppet|google_guest_agent|snapd)"
  AND CommandLine =~ "(sh|bash|python|perl|nc|curl|wget)"
ORDER BY CreateTime DESC

Remediation & Verification Script

Run this Bash script (or roll it into your configuration management) to verify exposure and apply the patched GCP kernel. A reboot is mandatory — kernel updates do not take effect on a running system until restart.

#!/usr/bin/env bash
# USN-8728-1 verification and remediation for Ubuntu GCP kernel
set -euo pipefail

# Step 1: Confirm this host runs the GCP kernel flavor
CURRENT_KERNEL=$(uname -r)
echo "[+] Running kernel: ${CURRENT_KERNEL}"
if [[ "${CURRENT_KERNEL}" != *gcp* ]]; then
  echo "[!] Not a GCP kernel build — check USN-8728-1 applicability manually."
  exit 0
fi

# Step 2: Identify CPU architecture (Arm vs AMD Zen 2 exposure)
ARCH=$(uname -m)
CPU_MODEL=$(grep -m1 'model name' /proc/cpuinfo | cut -d: -f2- | xargs || echo "unknown")
echo "[+] Architecture: ${ARCH} | CPU: ${CPU_MODEL}"

# Step 3: Pull updated package metadata and apply the kernel update
sudo apt-get update
sudo apt-get install --only-upgrade -y linux-image-gcp linux-headers-gcp || \
  sudo apt-get dist-upgrade -y

# Step 4: Confirm the candidate kernel is newer than the running kernel
INSTALLED=$(dpkg -l 'linux-image-*gcp*' 2>/dev/null | awk '/^ii/{print $2, $3}' | sort -V | tail -1)
echo "[+] Installed GCP kernel package: ${INSTALLED}"
echo "[i] Running kernel ${CURRENT_KERNEL} remains in effect until reboot."

# Step 5: Check whether a reboot is pending and schedule it
if [[ -f /var/run/reboot-required ]]; then
  echo "[!] REBOOT REQUIRED to load patched kernel."
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi

# Step 6 (post-reboot): verify — rerun 'uname -r' and confirm the version matches the patched package
# uname -r && apt list --installed 2>/dev/null | grep linux-image | grep gcp

Remediation

1. Apply USN-8728-1 immediately to all Ubuntu GCP instances: sudo apt-get update && sudo apt-get install --only-upgrade linux-image-gcp (or a full dist-upgrade to capture the additional kernel fixes bundled in this notice).
2. Reboot every patched host. Until the running kernel is replaced, the vulnerabilities remain fully exploitable. Prioritize reboots for multi-tenant hosts, container nodes, bastions, and CI/CD runners.
3. Verify post-reboot with uname -r — the running kernel must match the patched GCP kernel package delivered by the notice.
4. Check AMD microcode. For Zen 2 hosts, confirm your cloud provider (or firmware supply chain, for bare metal) has applied any required microcode updates complementing the kernel-side mitigation for CVE-2025-54518.
5. Reduce the local-attack surface while patching: enforce workload isolation (no untrusted containers on shared nodes), restrict interactive shell access, and enable kernel.unprivileged_bpf_disabled=1 and restricted perf_event_paranoid settings to constrain common local-exploit tooling.
6. Baseline and monitor using the detections above — on unpatched hosts, a UID-0 transition from a non-root session is a high-fidelity escalation signal.

Official advisory: USN-8728-1 — Ubuntu Security Notices. No CISA KEV deadline currently exists for these CVEs, but do not let the absence of a KEV entry drive your prioritization — local kernel privilege escalations are force multipliers in every intrusion chain.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub