USN-9043-1: Ubuntu Linux Kernel (NVIDIA) Vulnerability Batch — Patching, SEV-SNP Integrity Risks, and Detection Guidance

Canonical has published USN-9043-1, a security update for the Linux kernel in NVIDIA-flavored Ubuntu builds (the linux-nvidia kernel packages used on NVIDIA GPU and Grace/Jetson-class systems). The notice rolls up fixes across a broad set of kernel subsystems — ARM64, ARM32, MIPS, OpenRISC, PowerPC, RISC-V, S390, and x86 architecture code, NVDIMM (persistent memory) drivers, the kernel Cryptographic API, and the Handshake API — and it explicitly calls out CVE-2023-20585, an AMD processor issue affecting the integrity of SEV-SNP confidential computing guests.

Two things should drive urgency for defenders here. First, this is the NVIDIA kernel flavor: these systems are frequently the GPU compute nodes running AI/ML workloads, VDI farms, and HPC clusters — high-value targets where a local kernel compromise hands an attacker the most sensitive data in the building. Second, CVE-2023-20585 undermines the core promise of AMD SEV-SNP: that guest memory remains integrity-protected even from a malicious or compromised hypervisor. If you run confidential computing workloads on EPYC hardware, this notice directly concerns the trust model you sold to your customers or compliance team.

This post breaks down what's affected, how to find exposed systems, what to hunt for while you patch, and how to verify remediation.

Technical Analysis

Affected products and platforms

USN-9043-1 applies to Ubuntu systems running the NVIDIA-specific kernel packages (linux-image-nvidia-* and related meta-packages). In practice, that means:

• Ubuntu LTS deployments on NVIDIA GPU servers and workstations using the linux-nvidia kernel flavor
• NVIDIA Grace Hopper / Grace CPU (ARM64) platforms, which aligns with the ARM64 architecture fixes in this notice
• Virtualized and confidential computing environments on AMD EPYC processors with SEV-SNP enabled (relevant to CVE-2023-20585)

Because the corrected flaws span architecture-specific code across ARM64, ARM32, MIPS, OpenRISC, PowerPC, RISC-V, S390, and x86, plus NVDIMM drivers, the Cryptographic API, and the Handshake API, the practical exposure is any local attacker — or any process running with local code execution — being able to escalate privileges, corrupt memory, or compromise system integrity depending on the subsystem involved. Consult the USN-9043-1 advisory page for the exact package versions fixed for your Ubuntu release; do not assume a generic apt upgrade covered the NVIDIA flavor if your apt pinning or hold configuration excludes it.

CVE-2023-20585 — AMD RMP check failure against SEV-SNP guests

The most strategically interesting flaw in this batch is CVE-2023-20585. Per the notice, certain AMD processors did not properly perform Reverse Map Table (RMP) checks when the IOMMU accessed specific host buffers. The RMP is the hardware-backed data structure at the heart of SEV-SNP: it enforces that each physical memory page belongs to exactly one owner (a specific guest, or the hypervisor) and that page state transitions are authorized. If RMP validation is skipped for IOMMU-initiated accesses, a local attacker with hypervisor-level access can trigger an out-of-bounds condition and compromise the integrity of SEV-SNP guest memory.

From a defender's perspective, the exploitation requirements matter:

• Local access with hypervisor privileges is required. This is not a remote, unauthenticated bug. The threat model is a malicious cloud operator insider, a co-tenant who has already compromised the hypervisor, or an attacker who chained this with a separate hypervisor compromise.
• The impact is integrity, not disclosure. The attacker can tamper with guest memory contents — injecting code or altering data inside a confidential VM the customer believes is hardware-protected.
• It breaks attestation assumptions. SEV-SNP's value proposition is that even a hostile hypervisor cannot forge or tamper with guest state. CVE-2023-20585 is a crack in that guarantee, which is why cloud providers and anyone marketing confidential-computing isolation must treat the firmware and kernel updates as mandatory, not routine.

The remaining flaws in USN-9043-1 follow the classic multi-subsystem kernel rollup pattern: individually, many require local access; collectively, they represent the standard local privilege escalation and memory-corruption surface that ransomware operators and post-exploitation tooling abuse after initial access. Kernel LPEs are a staple of attacker tooling precisely because they convert any foothold — a compromised service account, a web shell, a CI runner — into root.

Exploitation status

At the time of writing, CVE-2023-20585 is not listed in CISA's Known Exploited Vulnerabilities catalog, and there is no public evidence of in-the-wild exploitation of the specific flaws addressed in USN-9043-1. The practical risk profile is: (1) post-exploitation privilege escalation on GPU compute nodes, where any local foothold becomes root; and (2) integrity attacks against SEV-SNP guests in environments where the hypervisor itself is not fully trusted. Both are realistic scenarios for targeted intrusions even without a public PoC.

Detection & Response

Kernel-level flaws are notoriously hard to detect pre-exploitation — the fix is the control. But defenders have two legitimate detection opportunities: (1) spotting the post-exploitation behavior that follows a local kernel compromise (out-of-tree module loads, tampering with /boot and module directories), and (2) catching the hardware-level signatures of RMP/SEV-SNP integrity violations in kernel logs, which is directly relevant to CVE-2023-20585.

Sigma rules

---
title: Out-of-Tree Kernel Module Load from Suspicious Path
id: 3f8a1c92-6b4d-4e71-9a2c-5d7e8f901234
status: experimental
description: Detects insmod/modprobe loading kernel modules from world-writable or user-controlled paths, a common post-exploitation step following local kernel privilege escalation such as the flaws patched in USN-9043-1.
references:
  - https://ubuntu.com/security/notices/USN-9043-1
  - https://attack.mitre.org/techniques/T1547/006/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1547.006
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/insmod'
      - '/modprobe'
  selection_path:
    CommandLine|contains:
      - '/tmp/'
      - '/dev/shm/'
      - '/var/tmp/'
      - '/home/'
  condition: selection_img and selection_path
falsepositives:
  - Developer workstations compiling and testing out-of-tree modules
  - Vendor GPU driver installers (rare with insmod from user paths)
level: high
---
title: AMD SEV-SNP RMP Violation or Memory Integrity Fault in Kernel Log
id: 8c2e5a47-1f93-4b6d-bd28-4e6a7c901835
status: experimental
description: Detects kernel log entries indicating RMP faults, SEV-SNP validation failures, or IOMMU page faults, which may indicate attempted or successful integrity violations against SEV-SNP guests as described in CVE-2023-20585 (USN-9043-1).
references:
  - https://ubuntu.com/security/notices/USN-9043-1
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.defense_evasion
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'RMP fault'
    - 'rmpupdate'
    - 'SEV-SNP: Memory rmp entry'
    - 'sev_snp'
    - 'SNP guest request failed'
    - 'amd_iommu.*page fault'
  condition: selection
falsepositives:
  - Legitimate SEV-SNP guest launch/teardown churn on heavily loaded hosts (tune with baselining)
  - Firmware bugs generating benign RMP warnings on older microcode
level: high
---
title: Unauthorized Write to Kernel Module or Boot Directories
id: 5a1d7b36-8e42-4f59-ac93-2b4c6d8e0127
status: experimental
description: Detects file modification activity in kernel module and boot directories by processes other than the package manager, consistent with post-exploitation tampering after local kernel privilege escalation.
references:
  - https://ubuntu.com/security/notices/USN-9043-1
  - https://attack.mitre.org/techniques/T1547/006/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1547.006
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/lib/modules/'
      - '/boot/vmlinuz'
      - '/boot/initrd'
  filter_pkgmgr:
    Image|endswith:
      - '/apt'
      - '/apt-get'
      - '/dpkg'
      - '/unattended-upgrade'
      - '/snapd'
  condition: selection and not filter_pkgmgr
falsepositives:
  - DKMS rebuilds during driver updates (correlate with maintenance windows)
  - Configuration management agents (Ansible, Chef) — scope filters to your tooling
level: high

KQL (Microsoft Sentinel / Defender)

Even for Linux infrastructure, Sentinel is a viable hunting plane if you forward syslog/CEF from your GPU nodes and hypervisors — which you should be doing for exactly this class of event. The query below hunts kernel-log indicators of SEV-SNP/RMP integrity faults (CVE-2023-20585) and then pivots to suspicious module-load activity. Run it across a 7–14 day lookback and baseline against known firmware noise.

// Hunt 1: SEV-SNP / RMP integrity fault indicators in forwarded Linux syslog (USN-9043-1 / CVE-2023-20585)
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName =~ "kernel"
| where SyslogMessage has_any ("RMP fault", "rmpupdate", "SEV-SNP", "SNP guest request failed")
   or (SyslogMessage has "amd_iommu" and SyslogMessage has "page fault")
| project TimeGenerated, Computer, Facility, SeverityLevel, SyslogMessage
| sort by TimeGenerated desc
;
// Hunt 2: Out-of-tree kernel module loads from user-controlled paths (post-LPE staging)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("insmod", "modprobe")
| where SyslogMessage has_any ("/tmp/", "/dev/shm/", "/var/tmp/", "/home/")
| project TimeGenerated, Computer, HostIP, SyslogMessage
| sort by TimeGenerated desc

Velociraptor VQL

For live triage of a suspected compromised node, this artifact captures the running kernel identity and the loaded module list so you can (a) confirm whether the host is still on a pre-USN-9043-1 kernel and (b) spot modules that don't belong. Compare module names against a known-good manifest from a freshly patched reference host.

-- USN-9043-1 triage: kernel version exposure and loaded module audit (Linux)
LET kernel_version = SELECT Line AS KernelVersion
FROM parse_lines(filename="/proc/version")

LET loaded_modules = SELECT
    split(string=Line, sep=" ")[0] AS ModuleName,
    split(string=Line, sep=" ")[1] AS ModuleSize,
    Line AS RawEntry
FROM parse_lines(filename="/proc/modules")

SELECT * FROM kernel_version
UNION ALL
SELECT format(format="Loaded module: %v (size %v)", args=[ModuleName, ModuleSize]) AS KernelVersion FROM loaded_modules

On a fleet scale, deploy this as a hunt and diff the module lists across nodes in the same cluster — a single host with an extra out-of-tree module is your anomaly.

Remediation and verification script

The following Bash script verifies whether a host runs the NVIDIA kernel flavor, applies the USN-9043-1 updates, checks SEV-SNP status where applicable, and flags whether a reboot is still pending. Run it via your configuration management tooling across the fleet and collect the output centrally.

#!/usr/bin/env bash
# USN-9043-1 remediation & verification — Ubuntu NVIDIA kernel flavor
# Run as root. Review before fleet-wide execution.
set -euo pipefail

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

echo "=== Installed NVIDIA kernel packages ==="
dpkg -l 'linux-image*nvidia*' 'linux-headers*nvidia*' 2>/dev/null | grep '^ii' || echo "No nvidia kernel flavor packages found - verify which USN applies to this host."

echo "=== Applying updates ==="
apt-get update
# Target the nvidia flavor meta-packages explicitly so apt holds/pinning don't silently skip them
apt-get install --only-upgrade -y $(dpkg -l 'linux-image*nvidia*' 'linux-headers*nvidia*' 'linux-modules*nvidia*' 2>/dev/null | awk '/^ii/{print $2}') || apt-get -y full-upgrade

echo "=== Ubuntu Pro / security status (if enrolled) ==="
(command -v pro >/dev/null && pro security-status) || true

echo "=== Reboot requirement ==="
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT REQUIRED. Pending kernel: $(cat /var/run/reboot-required.pkgs 2>/dev/null | tr '\n' ' ')"
else
  echo "No reboot flag set. Confirm running kernel matches the patched version from USN-9043-1."
fi

echo "=== SEV-SNP status (AMD confidential computing hosts) ==="
if [ -d /sys/module/kvm_amd ]; then
  dmesg | grep -iE 'SEV-SNP|RMP' | tail -n 20 || echo "No SEV-SNP/RMP messages in current dmesg buffer."
  echo "NOTE: CVE-2023-20585 is a processor/IOMMU issue - confirm AMD microcode/AGESA firmware updates from your OEM in addition to this kernel patch."
else
  echo "kvm_amd not present - host is not an AMD virtualization host."
fi

echo "=== Post-reboot verification command ==="
echo "After reboot, run: uname -r  and compare against the fixed version listed at https://ubuntu.com/security/notices/USN-9043-1"

Remediation

1. Patch the NVIDIA kernel flavor explicitly. Apply the updated linux-image-nvidia-*, linux-headers-nvidia-*, and linux-modules-nvidia-* packages per USN-9043-1 for your Ubuntu release. A generic apt upgrade can silently skip held or pinned kernel meta-packages — verify, don't assume. Reboot into the new kernel; until you do, the vulnerable kernel is still running.
2. Update AMD platform firmware for CVE-2023-20585. The RMP check failure is a processor/IOMMU behavior. Kernel updates are necessary but confirm with your hardware OEM/cloud provider that AGESA/microcode updates addressing CVE-2023-20585 are applied on SEV-SNP hosts. If you're a cloud customer, ask your provider directly whether their SEV-SNP fleet is patched — this is a legitimate attestation-scope question.
3. Prioritize by exposure. First tier: multi-tenant hypervisors, SEV-SNP hosts, and GPU compute nodes accessible to untrusted users or CI/CD workloads. Second tier: single-tenant GPU workstations and inference servers. Kernel LPEs matter most where local code execution by semi-trusted principals is normal — build runners, JupyterHub nodes, shared research clusters.
4. Enroll in Ubuntu Pro / esm-infra where applicable so pro security-status gives you an authoritative per-host view of outstanding kernel CVEs, and enable unattended security upgrades for kernel packages with a controlled reboot cadence (maintenance windows, kexec where supported).
5. Reduce the local attack surface while patching rolls out: restrict interactive shell access on GPU nodes, disable unprivileged user namespaces where workloads permit (kernel.unprivileged_userns_clone=0), and ensure kptr_restrict and dmesg_restrict are set to limit information leakage useful to exploit developers.
6. Hunt before and after. Deploy the Sigma rules and the Sentinel KQL above with a 14-day retrospective window. A host that was compromised before patching remains compromised after patching — kernel updates do not evict an attacker who already achieved root.
7. Track your patch SLA. There is no CISA KEV mandate attached to this notice as of publication, but treat kernel rollups touching confidential-computing integrity as a 14-day maximum remediation target for production hypervisors and a 30-day target for the remaining fleet, consistent with most NIST CSF / CIS Controls v8 aligned programs.

Related Resources

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