← Back to Feed CACHED · 2026-09-26 15:50:06 · CACHE_KEY CVE-2026-31635
CVE-2026-31635 · CWE-130 · Disclosed 2026-04-24

Linux Kernel rxgk Missing COW Guard in rxgk_decrypt_skb Allows Local Privilege Escalation (DirtyDecrypt)

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like finding a master key that only fits doors installed in three buildings out of the entire campus

CVE-2026-31635 is a Linux kernel flaw in the RxGK security class for the RxRPC protocol — the transport layer used by the Andrew File System (AFS). The function rxgk_verify_response() contains an inverted length check: it accepts oversized RESPONSE authenticator payloads instead of rejecting them. These payloads reach rxgk_decrypt_skb(), which performs AES-CBC decryption without a copy-on-write guard on shared page-cache pages. An unprivileged local user can weaponize this to corrupt the page cache of privileged files (/etc/shadow, /etc/sudoers, SUID binaries) and escalate to root. A separate remote denial-of-service path exists where a crafted rxrpc packet triggers a BUG_ON(len) kernel panic in skb_to_sgvec(). The bug affects kernels compiled with CONFIG_RXGK=y or CONFIG_RXGK=m and is fixed in upstream stable releases 6.18.23, 6.19.13, and 7.0. Affected-by-default distributions are limited to Fedora, Arch Linux, and historically openSUSE Tumbleweed. Enterprise stalwarts — RHEL, CentOS/Rocky/Alma, Ubuntu LTS, Debian Stable, and SUSE Enterprise — do not ship CONFIG_RXGK enabled and are not vulnerable in default configurations.

The NVD's vendor CVSS of 7.5 (HIGH) uses the network vector AV:N to model the remote DoS path, which is technically correct but practically misleading: the number of systems exposing rxrpc services to a network is vanishingly small, and availability-only impact (C:N/I:N/A:H) undersells the real danger. The more impactful attack is the local privilege escalation (DirtyDecrypt), which Red Hat separately scored at 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). SUSE went lower, rating it Moderate at 5.5 and marking all their enterprise products as 'Not affected.' Ubuntu assigned Medium priority. The vendor 7.5 HIGH label is therefore overstated for enterprise defenders: it conflates a theoretical network DoS on a protocol almost nobody runs with a local root exploit that only fires on rolling-release distros that most enterprises avoid in production.

"Root on rolling-release Linux via page cache corruption, but enterprise distros are immune by default"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain unprivileged shell on CONFIG_RXGK host

The attacker acquires local user access on a Linux host running Fedora, Arch, or another distribution that ships CONFIG_RXGK=y/m. Access may come via SSH with stolen credentials, a compromised web application, a container breakout, or physical access. No special privileges are needed — any unprivileged user account suffices.
Conditions required:
  • Target runs a kernel with CONFIG_RXGK compiled in (Fedora, Arch, openSUSE Tumbleweed)
  • Attacker has or obtains unprivileged local shell access
Where this breaks in practice:
  • Enterprise Linux (RHEL, Ubuntu LTS, Debian, SUSE) does not enable CONFIG_RXGK — >85% of enterprise fleets are immune by default
  • Requires prior access — the attacker is already past the perimeter
Detection/coverage: SSH login anomaly detection; EDR agent process creation alerts; container runtime audit logs
STEP 02

Trigger rxgk decryption without COW guard

The attacker runs the DirtyDecrypt PoC (from v12-security/pocs/dirtydecrypt), which creates an rxrpc socket and sends a crafted RESPONSE packet with an oversized authenticator length value. Due to the inverted check in rxgk_verify_response(), the kernel accepts the payload and passes it to rxgk_decrypt_skb() for AES-CBC decryption. Because the COW guard is missing, the decryption writes directly into a shared page-cache page instead of a private copy.
Conditions required:
  • Kernel allows unprivileged users to create AF_RXRPC sockets
  • CONFIG_RXGK module is loaded or built-in
Where this breaks in practice:
  • Some hardened container runtimes (gVisor, Kata) intercept or block AF_RXRPC socket creation
  • Seccomp profiles that restrict socket() syscall families can block the initial socket creation
Detection/coverage: Kernel audit subsystem (auditd) with socket syscall rules for AF_RXRPC family; kernel crash logs if BUG_ON fires before LPE succeeds
STEP 03

Corrupt page cache of privileged files

By carefully choosing the target file and offset, the attacker's decryption output overwrites page-cache contents of a privileged file — such as /etc/shadow, /etc/sudoers, or a SUID binary. The page cache is shared across the system, so subsequent reads of the corrupted file by privileged processes (e.g., su, sudo, login) consume the attacker-controlled content. The PoC reliably targets known offsets in standard Fedora/Arch file layouts.
Conditions required:
  • Target privileged files are present in the page cache (typical on running systems)
  • No integrity monitoring blocks or reverts the page-cache change in real time
Where this breaks in practice:
  • Immutable root filesystems (Fedora CoreOS ostree, systemd-veritysetup) may detect or prevent modification at read time
  • File integrity monitoring (AIDE, OSSEC, Samhain) can raise alerts on shadow/sudoers hash changes — but after the fact, not in real time
Detection/coverage: File integrity monitoring alerts on /etc/shadow, /etc/sudoers, SUID binary modifications; dm-verity violations on immutable-root systems
STEP 04

Escalate to root

The attacker authenticates with the modified credentials or executes the corrupted SUID binary to gain a root shell. From root, the attacker can install persistence, pivot laterally, or exfiltrate data. On Kubernetes worker nodes, root on the host enables container escape and access to other pods' secrets and volumes.
Conditions required:
  • Page cache corruption succeeded in step 3
  • Modified file is read by a privileged process before cache eviction
Where this breaks in practice:
  • Well-configured EDR should detect unexpected root shell spawning from non-standard parent processes
  • Kubernetes pod security standards (restricted profile) limit the blast radius even if the node is compromised
Detection/coverage: EDR root shell alerts; Kubernetes audit logs for privilege escalation events; anomalous process trees
03 · Compensating Control

1
HIGH 6.0→LOW 2.0
SEVERITY REDUCED
Blacklist the rxrpc and rxgk kernel modules — Run echo 'blacklist rxrpc' | sudo tee /etc/modprobe.d/disable-rxrpc.conf && echo 'blacklist rxgk' | sudo tee -a /etc/modprobe.d/disable-rxrpc.conf && sudo dracut -f (Fedora) or equivalent. This prevents the vulnerable code path from loading entirely without requiring a kernel update. Breaks AFS connectivity and IPsec if esp4/esp6 are also blacklisted — verify no AFS or rxrpc dependencies exist first. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity. No reboot required if modules are not currently loaded; sudo modprobe -r rxgk rxrpc unloads them live.
2
HIGH 6.0→IGNORE 0.0
SEVERITY REDUCED
Patch to fixed kernel versions — Update affected Fedora/Arch hosts to kernels ≥6.18.23 (6.18 stable), ≥6.19.13 (6.19 stable), or ≥7.0 (mainline). Fedora: sudo dnf upgrade --refresh kernel. Arch: sudo pacman -Syu linux. This is the definitive fix. Deploy within 180 days per the noisgate remediation SLA for HIGH severity. Schedule reboot windows for affected hosts.
3
HIGH 6.0→MEDIUM 4.5
SEVERITY REDUCED
Restrict AF_RXRPC socket creation via seccomp — Apply a seccomp profile that denies socket(AF_RXRPC, ...) calls to non-root users. In Kubernetes, enforce this via a SeccompProfile in the pod security context. This blocks the initial step of the DirtyDecrypt exploit chain without disabling the module entirely. Useful as defense-in-depth on container worker nodes where module blacklisting requires node-level access. Deploy within 30 days.
4
HIGH 6.0→MEDIUM 4.0
SEVERITY REDUCED
Enable dm-verity or immutable root filesystem — On Fedora CoreOS and similar systems, ensure ostree immutable root and dm-verity are active. This prevents the page-cache corruption from persisting to disk and causes verification failures when privileged processes attempt to read corrupted pages. Effective specifically for the page-cache write path (step 3 of the attack chain). This is a structural defense that also mitigates the broader Copy Fail family.
What doesn't work
  • Network firewalling / blocking rxrpc ports — Blocks the remote DoS path but does NOT prevent the local privilege escalation, which is the primary threat. The LPE uses local AF_RXRPC sockets, not network-exposed services.
  • SELinux in enforcing mode (standard targeted policy) — The standard Fedora targeted policy does not restrict AF_RXRPC socket creation by confined user domains. The page-cache corruption occurs in kernel space below MAC enforcement. A custom SELinux policy restricting rxgk operations could help but is not available off-the-shelf.
  • Restricting sudo access — Irrelevant. DirtyDecrypt achieves root via page-cache corruption of /etc/shadow or SUID binaries, bypassing sudo entirely.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo evidence. Not listed on CISA KEV. No campaigns or threat actor usage documented as of 2026-09-26. The related 'Copy Fail' family (CVE-2026-31431) saw some post-disclosure activity but CVE-2026-31635 specifically has not.
Proof-of-conceptPublic and weaponized. The *DirtyDecrypt* (aka *DirtyCBC*) PoC was released ~May 19, 2026 by V12 Security and Luna Tong (Zellic, aliases cts/gf_256). GitHub repos: v12-security/pocs/dirtydecrypt, 0xBlackash/CVE-2026-31635. Reliably achieves root on Fedora and Arch.
EPSS0.0063 (0.63%) — bottom quartile. Reflects the narrow CONFIG_RXGK exposure surface. The model correctly identifies limited real-world exploitability.
CISA KEVNot listed. No federal mandate to patch on an accelerated timeline.
CVSS vectorsNVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H → 7.5 (models remote DoS). Red Hat: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H → 7.8 (models LPE). SUSE: 5.5 Moderate (AV:L, A:H only). The LPE vector is more representative of actual risk.
Affected versionsLinux kernels with CONFIG_RXGK enabled, prior to stable fixes 6.18.23, 6.19.13, and 7.0. Ubuntu backport: 6.17.0-40.40 (25.10). SUSE Liberty Linux: 6.12.0-211.40.1.el10_2.
Fixed versionsUpstream: 6.18.23, 6.19.13, 7.0. Fedora: dnf upgrade kernel. Arch: pacman -Syu linux. Ubuntu 24.04 HWE: linux-hwe-6.17 6.17.0-40.40. Fix merged mainline April 25, 2026.
Exposure dataAFS/rxrpc services on Shodan and Censys are negligible (<500 globally). The network DoS vector is essentially theoretical. GreyNoise shows no scanning activity targeting rxrpc ports for this CVE.
Distro CONFIG_RXGK statusEnabled by default: Fedora, Arch Linux. Not enabled: RHEL 8/9, CentOS Stream, Rocky, Alma, Ubuntu LTS (20.04–26.04), Debian Stable, SUSE Enterprise, openSUSE Leap. SUSE confirmed all enterprise products 'Not affected.'
Researcher / disclosureIndependent discovery by V12 Security (reported May 9, 2026; told it was a duplicate of already-patched issue). Attribution by Will Dormann (Tharros). Part of the 'Copy Fail' family alongside CVE-2026-31431, CVE-2026-43284, CVE-2026-43500, and CVE-2026-46300. Patch merged upstream April 25, 2026.

Sources.

  1. The Hacker News — DirtyDecrypt PoC Released
  2. BleepingComputer — DirtyDecrypt Linux Root Escalation
  3. SecurityWeek — PoC Released for DirtyDecrypt
  4. Ubuntu Security — CVE-2026-31635
  5. Red Hat Security — CVE-2026-31635
  6. SUSE Security — CVE-2026-31635
  7. Uganda CERT — DirtyDecrypt Technical Advisory
  8. GitHub PoC — 0xBlackash/CVE-2026-31635
05 · The Call

Final Verdict
= UNCHANGED to HIGH (6.0/10)

Why this verdict

  • CONFIG_RXGK gating eliminates >85% of enterprise Linux. RHEL, CentOS/Rocky/Alma, Ubuntu LTS, Debian Stable, and SUSE Enterprise do not compile CONFIG_RXGK. Only Fedora and Arch ship it enabled. In a typical 10,000-host enterprise, the affected population is 500–1,500 developer workstations and a handful of CI runners — not production infrastructure.
  • Local access prerequisite compounds the narrowing. The DirtyDecrypt LPE requires an unprivileged shell on the target host. This is a post-initial-access technique — the attacker already breached the perimeter. The NVD's AV:N vector models a remote DoS via rxrpc, but rxrpc/AFS network exposure is effectively zero in modern enterprises (<500 instances globally on Shodan).
  • No in-the-wild exploitation and bottom-quartile EPSS (0.63%). Despite a public, reliable PoC available since May 2026, there is no documented use in campaigns, no KEV listing, and no GreyNoise scanning activity. The narrow CONFIG_RXGK prerequisite makes this unattractive compared to more broadly applicable kernel LPEs.
  • Role multiplier: The Linux kernel is a canonically high-value component, BUT the CONFIG_RXGK gating narrows the affected installed base to rolling-release distros. Of Fedora/Arch installs in enterprise: (a) *Low-value role (80–90%):* developer workstations — root here means one compromised dev machine, blast radius = host. (b) *Typical role (5–10%):* CI runners, test servers — root enables supply-chain pivot if CI secrets are accessible, blast radius = pipeline. (c) *High-value role (5–10%):* Fedora CoreOS Kubernetes worker nodes — root enables pod escape and lateral movement, blast radius = cluster. The high-value role (K8s workers on Fedora CoreOS) represents >1% of the CONFIG_RXGK-enabled installed base, so the verdict floor is HIGH. However, the vast majority of enterprise K8s runs RHEL CoreOS, Ubuntu, or Amazon Linux — not Fedora CoreOS — limiting real exposure further.
  • Vendor score disagreement confirms overstatement. NVD 7.5 (AV:N DoS), Red Hat 7.8 (AV:L LPE), SUSE 5.5 (Moderate), Ubuntu Medium priority. The NVD score models a network DoS on a protocol almost no one exposes. Adjusting for CONFIG_RXGK prevalence, local-access requirement, and zero wild exploitation, the effective severity sits at the floor: HIGH 6.0.

Why not higher?

The PoC is public and reliable, and root on a Kubernetes worker node is a serious blast-radius scenario. However, the chain requires two compounding prerequisites (local access AND CONFIG_RXGK enabled) that together reduce the reachable population to <10% of enterprise Linux. No threat actor has adopted it despite four months of PoC availability, and the NVD's AV:N vector is misleading — the remote DoS targets a protocol with near-zero enterprise deployment. There is no justification for CRITICAL when the canonical high-value-role component (the kernel) is only affected in a narrow, non-production-dominant configuration.

Why not lower?

A working, weaponized PoC (DirtyDecrypt) reliably grants root from an unprivileged user on affected kernels. Fedora CoreOS Kubernetes worker nodes with CONFIG_RXGK represent a plausible high-value-role scenario where root on the host leads to cluster-level compromise. This >1% high-value-role share floors the verdict at HIGH. Additionally, the bug is part of the active 'Copy Fail' family of kernel page-cache LPEs, suggesting ongoing researcher and potential attacker interest in this attack surface. Dropping to MEDIUM would undercount the risk for the minority of enterprises running Fedora-based infrastructure in production roles.

06 · Verification

Crowdsourced verification payload.

Run directly on each target Linux host as any user (root not required). Invoke with: bash cve-2026-31635-check.sh. The script checks whether CONFIG_RXGK is compiled into the running kernel and whether the kernel version predates the upstream fix. Note: distro-specific backport versions (e.g., Ubuntu 6.17.0-40.40) may report UNKNOWN — cross-reference with dpkg -l linux-image-$(uname -r) or rpm -q kernel for exact package status.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-31635 (DirtyDecrypt) vulnerability checker
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN
set -euo pipefail

KVER=$(uname -r)
echo "[*] Running kernel: $KVER"

# Step 1: Determine CONFIG_RXGK status
rxgk_enabled() {
  local cfg="/boot/config-${KVER}"
  if [ -f "$cfg" ]; then
    grep -qE '^CONFIG_RXGK=[ym]' "$cfg" 2>/dev/null && return 0
    return 1
  fi
  if [ -f /proc/config.gz ]; then
    zcat /proc/config.gz 2>/dev/null | grep -qE '^CONFIG_RXGK=[ym]' && return 0
    return 1
  fi
  # Fallback: check if rxgk module exists on disk
  if modinfo rxgk >/dev/null 2>&1; then
    return 0
  fi
  return 2
}

rxgk_enabled
rc=$?
if [ "$rc" -eq 1 ]; then
  echo "[+] CONFIG_RXGK is NOT enabled — system is not vulnerable."
  echo "PATCHED"
  exit 1
elif [ "$rc" -eq 2 ]; then
  echo "[?] Cannot determine CONFIG_RXGK status (no kernel config or module found)."
  echo "UNKNOWN"
  exit 2
fi
echo "[!] CONFIG_RXGK is ENABLED in this kernel."

# Step 2: Parse upstream version components
MAJ=$(echo "$KVER" | cut -d. -f1)
MIN=$(echo "$KVER" | cut -d. -f2)
PAT=$(echo "$KVER" | cut -d. -f3 | sed 's/[^0-9].*//')
PAT=${PAT:-0}
echo "[*] Parsed upstream base: ${MAJ}.${MIN}.${PAT}"

# Step 3: Check against fixed upstream versions (6.18.23, 6.19.13, 7.0+)
patched=false
if [ "$MAJ" -ge 7 ]; then
  patched=true
elif [ "$MAJ" -eq 6 ]; then
  if [ "$MIN" -ge 20 ]; then
    patched=true
  elif [ "$MIN" -eq 19 ] && [ "$PAT" -ge 13 ]; then
    patched=true
  elif [ "$MIN" -eq 18 ] && [ "$PAT" -ge 23 ]; then
    patched=true
  fi
fi

if $patched; then
  echo "[+] Kernel ${MAJ}.${MIN}.${PAT} includes the upstream fix."
  echo "PATCHED"
  exit 1
fi

# Step 4: Check if rxgk module is currently loaded (active risk)
if lsmod 2>/dev/null | grep -q rxgk; then
  echo "[!!] rxgk module is LOADED — actively exploitable."
else
  echo "[!] rxgk module exists but is not currently loaded."
  echo "    Load-on-demand still makes this exploitable."
fi

echo "[-] Kernel ${KVER} with CONFIG_RXGK enabled is VULNERABLE to CVE-2026-31635 (DirtyDecrypt)."
echo "VULNERABLE"
exit 0