USN-8728-3: Linux Kernel CPU Flaws (CVE-2025-10263, CVE-2025-54518) — Detection and Patching Guide for Ubuntu/Oracle Kernels

Canonical published USN-8728-3, an update to the Oracle-flavored Linux kernel packages shipping in supported Ubuntu releases. The notice closes several security issues, but two of them deserve immediate attention from anyone running multi-tenant Linux workloads, container hosts, or shared build infrastructure:

• CVE-2025-10263 — On certain Arm processors, a broadcast TLB (translation lookaside buffer) invalidation can complete before memory writes made through the invalidated translation are globally observed. The practical consequence: a local attacker can write to memory after their permission to do so has been revoked. That is a textbook memory-protection bypass and a direct path to privilege escalation.
• CVE-2025-54518 — Certain AMD Zen 2 processors fail to properly isolate shared resources in the operation cache (op cache). A local attacker can leverage this to corrupt instructions that will later execute at a higher privilege level, again yielding unauthorized privilege gain.

Both flaws share the same exploitation prerequisite — local code execution — and the same devastating impact: escalation to kernel-level control. In modern environments, "local attacker" is not a comforting qualifier. Any container escape, any compromised CI runner, any webshell dropped by a perimeter bug, any malicious package in a developer's pipeline instantly becomes a full kernel compromise when one of these CPU-side flaws is reachable.

If you run Ubuntu systems with the Oracle kernel variant — common in cloud and Oracle Database-adjacent deployments — on Arm (AWS Graviton, Ampere, Oracle Cloud Ampere A1) or AMD Zen 2 (Rome-generation EPYC, Ryzen 3000/4000-series) hardware, treat this as a priority patch cycle, not a routine one.

Technical Analysis

CVE-2025-10263 — Arm TLB Invalidation Race

The TLB caches virtual-to-physical address translations. When the kernel revokes a mapping — for example, unmapping a page from a process or changing its permissions — it issues a TLB invalidation so stale, overly-permissive translations can't be used. On affected Arm cores, the broadcast invalidation can signal completion before writes issued through the stale translation are globally visible to the coherent memory system.

From a defender's perspective, the attack chain looks like this:

1. Attacker-controlled unprivileged process holds a writable mapping to a page.
2. The kernel (or a hypervisor/another process boundary) revokes that mapping — e.g., the page is repurposed for privileged data or permissions are tightened.
3. Because the invalidation completes prematurely, the attacker races the revocation window and lands a write through the stale translation into memory they no longer own.
4. Result: corruption of privileged memory, protection bypass, and privilege escalation.

This is a hardware-software contract violation — the kernel assumed the architecture guarantee ("invalidation complete means no further writes via that translation") held, and on these parts it doesn't. The kernel-side fix adds the necessary synchronization/barrier semantics around TLB maintenance operations.

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

Zen 2's op cache stores decoded macro-ops to skip the expensive decode pipeline on hot code paths. The flaw: resources in this cache are not properly isolated across privilege boundaries. A local attacker can influence shared op-cache state such that instructions executed later at a higher privilege level are corrupted.

The defensive significance:

1. Attacker primes/poisons shared op-cache state from unprivileged execution context.
2. A higher-privilege context (kernel or setuid path) executes code whose cached decoded ops have been tampered with.
3. Corrupted instruction execution at elevated privilege yields attacker-controlled kernel behavior.

Microcode-level and/or kernel mitigations address the isolation gap. Note this class of issue — cross-privilege contamination of shared microarchitectural state — is the same family as the speculative-execution and cache-isolation flaws that have haunted x86 since 2018. Zen 2 (EPYC "Rome," Ryzen 3000 desktop) remains heavily deployed in datacenters, so exposure is broad.

Affected Scope

• Product: Linux kernel, Oracle kernel flavor in supported Ubuntu LTS releases (see the USN for your exact release/kernel series).
• Hardware prerequisite: CVE-2025-10263 requires affected Arm silicon; CVE-2025-54518 requires AMD Zen 2. Systems on other microarchitectures are not exposed to these two specific CVEs, though the USN rolls up additional kernel issues.
• Attacker model: Local only — no remote vector is described. CVSS scoring at publication time should be confirmed against NVD/Ubuntu's CVE pages for your tracking; treat the impact (kernel privilege escalation) as high regardless of the local-attack discount.
• Exploitation status: No public in-the-wild exploitation or CISA KEV listing was reported at the time of this notice. That is the good news — but CPU-side local privilege escalations historically get absorbed into post-exploitation toolkits quickly once researchers publish analysis. Patch before that happens.

Detection & Response

Honest practitioner note: you cannot signature-detect the CPU race itself from userland telemetry. What you can detect is the outcome — an unprivileged process that suddenly executes in kernel context, unexpected privilege transitions, tampering with privileged binaries, and kernel taint events that follow successful exploitation. The rules below target exactly those observable post-exploitation behaviors, which is where a local privilege escalation actually shows up in your telemetry.

Sigma Rules

---
title: Unexpected Privilege Transition via Setuid or Capability Change on Linux
description: Detects non-root spawned processes gaining root execution context or invoking privilege-boundary tools, consistent with post-exploitation behavior after a local kernel privilege escalation such as CVE-2025-10263 or CVE-2025-54518.
references:
  - https://ubuntu.com/security/notices/USN-8728-3
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_privesc_tools:
    Image|endswith:
      - '/unshare'
      - '/nsenter'
      - '/capsh'
      - '/setpriv'
  selection_args:
    CommandLine|contains:
      - '--user'
      - '--map-root-user'
      - '--mount'
      - '--decode'
  condition: all of selection_*
falsepositives:
  - Container runtime and orchestration tooling legitimately invoking user-namespace operations
  - System administrators using unshare for namespace testing
level: medium
---
title: Kernel Module Load by Non-Package-Management Process on Linux
description: Detects kernel module insertion outside of legitimate package/system tooling. Successful exploitation of a local kernel privilege escalation frequently culminates in loading a rootkit module or tampering with kernel state.
references:
  - https://ubuntu.com/security/notices/USN-8728-3
  - https://attack.mitre.org/techniques/T1547/006/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1547.006
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/insmod'
      - '/modprobe'
      - '/kmod'
  filter_legit:
    ParentImage|endswith:
      - '/dpkg'
      - '/apt'
      - '/apt-get'
      - '/dkms'
      - '/systemd'
  condition: selection and not filter_legit
falsepositives:
  - Custom hardware enablement scripts
  - Vendor agents that load their own kernel modules (EDR, observability)
level: high
---
title: Unprivileged User Writing to System Binary or Configuration Paths
description: Detects writes to privileged filesystem locations (system binaries, sudoers, cron) from shells or interpreters, consistent with an attacker solidifying access after escalating privileges via a kernel flaw such as the Arm TLB race in CVE-2025-10263.
references:
  - https://ubuntu.com/security/notices/USN-8728-3
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.persistence
  - attack.defense_evasion
logsource:
  category: process_creation
  product: linux
detection:
  selection_shells:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/python'
      - '/python3'
      - '/perl'
  selection_redirect:
    CommandLine|contains:
      - '> /usr/bin/'
      - '>> /usr/bin/'
      - '> /usr/sbin/'
      - '>> /usr/sbin/'
      - '> /etc/sudoers'
      - '/etc/cron.d/'
      - 'tee /etc/'
      - 'tee /usr/'
  condition: all of selection_*
falsepositives:
  - Configuration management (Ansible/Chef) writing managed files — filter by parent process
  - Package installation activity
level: high

KQL — Microsoft Sentinel (Syslog/CEF ingestion from Linux hosts)

This query hunts for the post-exploitation signature of a local privilege escalation: auditd/sudo telemetry showing rapid or anomalous transitions from unprivileged accounts to root execution, clustered on hosts that report the vulnerable Oracle kernel. Deploy it after you've inventoried kernel versions so the VulnerableHost list reflects your actual exposure.

// Post-exploitation hunt: anomalous privilege transitions on Ubuntu/Oracle-kernel hosts
// Scope hosts running unpatched kernels first (maintain this list from your vuln scanner/CMDB)
let VulnerableHosts = dynamic(["web-oracle-01", "db-oracle-02"]); // replace with dynamic lookup from your asset table
let TimeWindow = 7d;
let RootExec =
    Syslog
    | where TimeGenerated > ago(TimeWindow)
    | where Computer in (VulnerableHosts)
    | where SyslogMessage has_any ("COMMAND=", "session opened for user root", "sudo:")
    | extend SrcUser = extract(@"sudo:\s+(\S+)\s+:", 1, SyslogMessage)
    | extend Command = extract(@"COMMAND=(.+)$", 1, SyslogMessage)
    | where isnotempty(SrcUser) or SyslogMessage has "session opened for user root";
RootExec
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
            Commands=make_set(Command, 20), EventCount=count()
    by Computer, SrcUser
| where EventCount > 20 or Commands has_any ("/bin/bash", "/bin/sh", "insmod", "modprobe", "unshare", "nsenter")
| project Computer, SrcUser, EventCount, FirstSeen, LastSeen, Commands
| order by EventCount desc;

Velociraptor VQL

Endpoint hunt to (a) inventory kernel versions against the patched baseline and (b) surface processes whose executable lives in a user-writable or anomalous path — a common artifact of a dropped local exploit binary.

-- USN-8728-3 exposure + local privilege-escalation artifact hunt (Linux)
-- 1) Kernel version inventory
SELECT * FROM foreach(
  row={ SELECT Uname.Sysname AS Sys, Uname.Release AS KernelRelease, Uname.Machine AS Arch FROM uname() },
  query={ SELECT Sys, KernelRelease, Arch,
          KernelRelease =~ 'oracle' AS IsOracleKernel FROM scope() })

-- 2) Root-owned processes executing from user-writable or temp paths
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Username =~ 'root'
  AND (Exe =~ '^/tmp/' OR Exe =~ '^/var/tmp/' OR Exe =~ '^/dev/shm/'
       OR Exe =~ '^/home/' OR Exe =~ 'deleted')

Remediation / Verification Script

Run this on candidate hosts to identify CPU exposure, confirm the Oracle kernel flavor, apply the USN, and verify the pending reboot state.

#!/usr/bin/env bash
# USN-8728-3 verification and remediation helper (Ubuntu, Oracle kernel flavor)
set -euo pipefail

echo "=== [1] Identify kernel flavor and running version ==="
uname -r
KERNEL=$(uname -r)
if [[ "$KERNEL" == *oracle* ]]; then
  echo "[!] Oracle kernel flavor detected — in scope for USN-8728-3"
else
  echo "[i] Non-Oracle kernel flavor. Check the parallel USN for your kernel series."
fi

echo "=== [2] CPU exposure check ==="
if [[ "$(uname -m)" == "aarch64" ]]; then
  echo "[!] ARM platform — CVE-2025-10263 (TLB invalidation race) potentially applicable"
  grep -m1 'CPU part' /proc/cpuinfo || true
elif grep -qi 'amd' /proc/cpuinfo; then
  FAMILY=$(grep -m1 'cpu family' /proc/cpuinfo | awk '{print $4}')
  MODEL=$(grep -m1 'model[[:space:]]' /proc/cpuinfo | awk '{print $3}')
  echo "[i] AMD cpu family=$FAMILY model=$MODEL"
  # Zen 2 = family 23 (0x17), models 0x30-0x7F range incl. Rome/Matisse
  if [[ "$FAMILY" == "23" ]]; then
    echo "[!] AMD Family 23 (Zen/Zen2). Cross-reference model with vendor guidance for CVE-2025-54518"
  fi
else
  echo "[i] Neither ARM nor AMD detected — these two CVEs likely not applicable to this host"
fi

echo "=== [3] Apply the USN update ==="
export DEBIAN_FRONTEND=noninteractive
apt-get update -qq
# Installs the latest Oracle-kernel metapackage containing the USN-8728-3 fixes
apt-get install --only-upgrade -y linux-image-oracle linux-headers-oracle 2>/dev/null \
  || apt-get dist-upgrade -y

echo "=== [4] Confirm candidate vs. running kernel ==="
CANDIDATE=$(apt-cache policy linux-image-oracle 2>/dev/null | awk '/Installed:/{print $2}')
echo "Running kernel : $KERNEL"
echo "Installed pkg  : ${CANDIDATE:-unknown}"

echo "=== [5] Reboot requirement ==="
if [[ -f /var/run/reboot-required ]]; then
  echo "[!] REBOOT REQUIRED — the patched kernel is not active until restart"
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
else
  echo "[i] No reboot pending"
fi

echo "=== [6] Also check AMD microcode currency (CVE-2025-54518) ==="
dpkg -l amd64-microcode 2>/dev/null | tail -n1 || echo "[i] amd64-microcode package not installed"
grep -m1 microcode /proc/cpuinfo || true

Remediation

1. Patch immediately. Apply USN-8728-3 via apt-get update && apt-get dist-upgrade (or targeted linux-image-oracle upgrade) on every Ubuntu host running the Oracle kernel flavor. Reboot — kernel updates are inert until the new image is running. Full advisory: https://ubuntu.com/security/notices/USN-8728-3. Cross-reference the sibling USNs for your other kernel flavors (generic, AWS, Azure, GCP) since the same fixes ship across series.
2. Inventory silicon. CVE-2025-10263 only matters on affected Arm cores; CVE-2025-54518 only matters on AMD Zen 2 (family 0x17, EPYC "Rome" / Ryzen 3000-4000 era). Build the exposure list from /proc/cpuinfo or your cloud instance metadata (Graviton/Ampere = Arm; Rome-generation EPYC instances = Zen 2). Prioritize multi-tenant, container, CI/CD, and jump-host systems where "local attacker" is a realistic adversary, not a theoretical one.
3. Update AMD microcode. Ensure the amd64-microcode package (and/or your hypervisor/firmware vendor's microcode update) is current — op-cache isolation fixes of this class are frequently delivered or complemented at the microcode layer. Check your server OEM's BIOS advisory as well.
4. Reduce the local-attacker blast radius while patching rolls out:
   • Enforce kernel.unprivileged_userns_clone=0 where your workload permits, and audit unshare/nsenter usage.
   • Confirm kernel.kptr_restrict=2, kernel.dmesg_restrict=1, and kernel.yama.ptrace_scope=1 (or higher) via sysctl — these don't fix the bugs but constrain post-exploitation reconnaissance.
   • Tighten who can get a shell at all: review sudoers, service accounts, and container escape surfaces (--privileged, host mounts, exposed docker sockets).
5. Validate with your vuln management platform. Confirm scanner plugins flag the pre-patch Oracle kernel versions, close the loop post-reboot, and track mean-time-to-patch for kernel CVEs as its own KPI — kernel LPEs are consistently among the first capabilities absorbed into commodity post-exploitation tooling once analysis becomes public.

There is no confirmed in-the-wild exploitation and no CISA KEV deadline at publication — which is exactly when you want to patch: before the exploit, not after.

Related Resources

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