CVE-2025-10263 & CVE-2025-54518: Ubuntu Azure Linux Kernel Privilege Escalation — Detection and Remediation Guide

Canonical has released USN-8728-2, the Azure-flavored follow-up to USN-8728-1, addressing two distinct CPU-architecture-dependent privilege escalation vulnerabilities in the Linux kernel, along with a bundle of additional security fixes. If you are running Ubuntu workloads on Azure — particularly on Arm-based (Ampere Altra/Cobalt) or AMD Zen 2 (EPYC Rome) VM SKUs — this is a patch-now event.

Two vulnerabilities anchor this update:

• CVE-2025-10263 — a memory-ordering race on Arm processors where a broadcast TLB invalidation can complete before memory writes made through the invalidated translation are globally observed. A local attacker can write to memory after their permission to do so has been revoked.
• CVE-2025-54518 — improper isolation of shared resources in the operation cache (op cache) on AMD Zen 2 processors, allowing a local attacker to corrupt instructions executing at a higher privilege level.

Both are local privilege escalation primitives. That means the exploitation precondition is an existing foothold — a compromised container, a rogue CI job, a malicious tenant workload, an SSH session from a low-privileged service account. In cloud environments where multi-tenancy, shared build runners, and container escape chains are everyday realities, local kernel LPEs are the second half of nearly every serious intrusion chain. Do not deprioritize these because they require local access.

Technical Analysis

Affected Products

• Ubuntu Linux kernel, Azure build (linux-azure) — the Azure-optimized kernel shipped for Ubuntu LTS releases on Azure VMs.
• Architectures of concern: Arm64 (CVE-2025-10263) and AMD Zen 2 / EPYC Rome (CVE-2025-54518).
• The notice also rolls up several additional kernel security issues, so the update is broader than the two named CVEs.

Official advisory: USN-8728-2 — ubuntu.com/security/notices/USN-8728-2. Pull the exact fixed package versions for your Ubuntu release from the advisory's package table — Canonical publishes per-release fixed versions there, and they differ between LTS releases.

CVE-2025-10263 — Arm TLB Invalidation Race

The bug is a memory-ordering defect in the interaction between the kernel and certain Arm CPUs. When the kernel revokes access to a memory mapping, it issues a broadcast TLB invalidation so that no core can continue translating through the stale entry. On affected processors, that invalidation can complete before writes made through the old translation have become globally visible to the rest of the system.

From a defender's perspective, the exploitation primitive is severe: an attacker-controlled process can write to physical memory after the kernel believes it has revoked that ability. That collapses the fundamental guarantee underpinning page-table-based isolation. Realistic outcomes include overwriting credential structures, corrupting page tables, or modifying kernel data — all classic roads from unprivileged code execution to ring 0.

Exploitation requirements: local code execution on an affected Arm64 system. No user interaction, no network vector.

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

AMD Zen 2 microarchitectures include an operation cache that stores decoded micro-ops for reuse. This vulnerability is a failure to properly isolate shared resources in that cache across privilege boundaries. A local attacker can leverage the defect to corrupt instructions that subsequently execute at a higher privilege level — meaning attacker-influenced microarchitectural state contaminates kernel or privileged execution.

This class of bug sits in the same family of CPU-side isolation failures that have repeatedly proven exploitable for privilege escalation on shared silicon. The concerning part for cloud operators: Zen 2 EPYC parts underpin a large installed base of Azure D/E-series generation VMs, and op-cache contamination attacks are attractive precisely because the exploit runs in userspace and leaves minimal syscall-level telemetry until the moment of privilege transition.

Exploitation Status

As of this writing, neither CVE is listed in the CISA Known Exploited Vulnerabilities catalog, and Canonical's notice describes both as issues a local attacker "could possibly use." Treat them as theoretical-but-weaponizable: hardware-isolation LPEs with clear primitives historically get working public exploits, and once a PoC drops, every low-privileged foothold on an unpatched host becomes a root shell. The correct posture is to patch before the PoC, not after.

Detection & Response

Honest assessment first: you will not reliably detect the microarchitectural race itself with telemetry. TLB invalidation ordering and op-cache contamination happen below the visibility floor of auditd, Sysmon-for-Linux, or eBPF syscall tracing. Your detection surface is post-exploitation behavior — the moment an exploit transitions from unprivileged userspace to root, loads a module, tampers with kernel state, or spawns an unexpected privileged shell. That is where you hunt.

Sigma Rules

Two focused rules targeting the highest-signal post-exploitation behaviors on Linux kernel LPE chains: user-namespace exploit staging (the dominant delivery vehicle for kernel LPEs) and unexpected privileged module loading.

---
title: Linux Kernel Exploit Staging via User Namespaces
id: 8f2c4a71-3b6d-4e59-a1c7-9d0e2f5a8b31
status: experimental
description: Detects unshare invocations combining user and mount/PID namespaces, a common staging step for local kernel privilege escalation exploits such as those targeting CVE-2025-10263 and CVE-2025-54518.
references:
  - https://ubuntu.com/security/notices/USN-8728-2
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/unshare'
  selection_flags:
    CommandLine|contains:
      - '-U'
      - '--user'
  selection_ns:
    CommandLine|contains:
      - '-m'
      - '--mount'
      - '-p'
      - '--pid'
      - 'map-root-user'
  condition: selection_img and selection_flags and selection_ns
falsepositives:
  - Rootless container runtimes (podman, rootless docker)
  - Legitimate sandboxing tools (bubblewrap-based builds)
level: medium
---
title: Kernel Module Load by Non-System Process
id: 3e7b9d42-6a15-4f08-b2c4-1d8e5a7c9036
status: experimental
description: Detects insmod/modprobe execution from interactive or service shells, consistent with post-exploitation kernel persistence following a local privilege escalation such as CVE-2025-10263 or CVE-2025-54518.
references:
  - https://ubuntu.com/security/notices/USN-8728-2
  - https://attack.mitre.org/techniques/T1547/006/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1547.006
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/insmod'
      - '/modprobe'
  filter_parent:
    ParentImage|endswith:
      - '/systemd'
      - '/kmod'
      - '/udevadm'
  filter_apt:
    ParentImage|contains:
      - '/apt'
      - '/dpkg'
  condition: selection and not 1 of filter_*
falsepositives:
  - Administrator maintenance activity
  - Driver installation scripts
level: high

The first rule is deliberately medium severity and tuned to require combined namespace flags — bare unshare usage is common in build tooling, but unshare -U -m with root-user mapping from a non-build host is exploit staging until proven otherwise. The second fires high because interactive insmod outside package management is nearly always malicious on production cloud VMs.

KQL Hunt (Microsoft Sentinel via Syslog/CEF ingestion)

Hunt Azure VMs for kernel-level distress signals and privilege transition events. Kernel oops, general protection faults, and taint events in the days before patching are your leading indicators of failed or partially failed exploit attempts against these CVEs — and failed attempts matter, because they prove someone is trying.

// Hunt for kernel fault/taint events and privilege escalation artifacts on Linux hosts
let lookback = 14d;
let KernelEvents =
    Syslog
    | where TimeGenerated > ago(lookback)
    | where Facility == "kern"
    | where SyslogMessage has_any ("general protection fault", "kernel NULL pointer dereference", "BUG: unable to handle", "Oops:", "tainted", "segfault at")
    | project TimeGenerated, Computer, SyslogMessage, SeverityLevel;
let PrivTransitions =
    Syslog
    | where TimeGenerated > ago(lookback)
    | where SyslogMessage has ("type=SYSCALL")
    | where SyslogMessage has_all ("setuid", "success=yes")
    | project TimeGenerated, Computer, SyslogMessage;
union KernelEvents, PrivTransitions
| summarize EventCount = count(), SampleMessages = make_set(SyslogMessage, 3) by Computer, bin(TimeGenerated, 1h)
| order by EventCount desc;

Follow up any host with a kernel fault cluster by checking whether it is still running a vulnerable linux-azure build and whether it also shows the namespace-staging or module-load behaviors from the Sigma rules above. A GPF followed minutes later by a root shell from the same service account is a full exploit chain — treat it as an IR event, not a patching ticket.

Velociraptor VQL Hunt

For DFIR triage of a suspect Azure VM, pull the running kernel build and look for root-owned interactive interpreters whose parentage does not trace to a legitimate daemon — the classic fingerprint of a local exploit that just won the race.

-- Triage kernel version and suspicious root interactive shells
LET kernel <= SELECT read_file(filename="/proc/version") AS KernelBuild
FROM scope()

LET shells <= SELECT Pid, Ppid, Name, Username, Exe, CommandLine, CreateTime
FROM pslist()
WHERE Username =~ "root"
  AND Name =~ "^(bash|sh|dash|zsh|python[0-9.]*|perl)$"

SELECT * FROM shells

Feed the /proc/version output from a fleet-wide hunt into your patch verification: any linux-azure build older than the fixed version listed in USN-8728-2 for that Ubuntu release is still exposed.

Remediation / Verification Script

Run this across your Azure Ubuntu estate (via Azure Run Command, Ansible, or your config management of choice) to identify and remediate vulnerable Azure kernels.

#!/bin/bash
# USN-8728-2 remediation and verification for Ubuntu Azure kernels
set -euo pipefail

echo "=== Current kernel ==="
uname -r

echo "=== CPU architecture check ==="
arch=$(uname -m)
if [ "$arch" = "aarch64" ]; then
  echo "[!] Arm64 host - CVE-2025-10263 (Arm TLB invalidation race) applies"
fi
if grep -qi "AuthenticAMD" /proc/cpuinfo && grep -q "family 23" /proc/cpuinfo; then
  echo "[!] AMD Zen 2-class CPU detected - CVE-2025-54518 (op cache isolation) applies"
fi

echo "=== Installed Azure kernel packages ==="
dpkg -l | grep -E 'linux-(image|headers|azure)' || echo "No linux-azure packages found - verify kernel flavor"

echo "=== Applying updates ==="
apt-get update -qq
DEBIAN_FRONTEND=noninteractive apt-get install --only-upgrade -y \
  linux-azure linux-image-azure linux-headers-azure 2>/dev/null || \
DEBIAN_FRONTEND=noninteractive apt-get upgrade -y linux-image-$(uname -r | sed 's/-azure$//') 2>/dev/null || true

echo "=== Reboot check ==="
if [ -f /var/run/reboot-required ]; then
  echo "[!] REBOOT REQUIRED - kernel patches do not take effect until reboot"
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
else
  echo "[+] No reboot pending"
fi

echo "=== Post-update kernel verification (after reboot) ==="
echo "Compare 'uname -r' output against fixed versions at https://ubuntu.com/security/notices/USN-8728-2"

Remediation

1. Patch immediately. Apply the updated linux-azure packages per USN-8728-2. Pull the exact fixed version strings for your Ubuntu LTS release from the advisory's package table — do not guess.
2. Reboot. Kernel updates are inert until the host reboots into the new image. A patched package with an unpatched running kernel is a false sense of compliance — your scanners will say "fixed" while the exploit still works. Track /var/run/reboot-required fleet-wide and enforce reboot SLAs.
3. Evaluate Ubuntu Livepatch for environments where reboot windows are hard to get. Canonical Livepatch may cover these fixes for Ubuntu Pro subscribers; verify coverage in the Livepatch portal rather than assuming it.
4. Prioritize by exposure model, not CVSS. Multi-tenant hosts, shared CI/CD runners, jump boxes, Kubernetes worker nodes with untrusted workloads, and any VM where non-administrators hold shell access go first. Single-purpose VMs with no local users can follow in the standard window.
5. Harden the preconditions. Where operationally acceptable, restrict unprivileged user namespaces (kernel.unprivileged_userns_clone=0 via sysctl) to shrink the delivery surface for kernel LPE exploits — understanding this will break rootless container workloads, so test per workload.
6. Hunt before and after. Run the KQL kernel-fault query across the last 14 days on exposed hosts. Exploit attempts that predated patching may have already succeeded; patching does not evict an attacker who is already root.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub