← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-31635 · CWE-130 · Disclosed 2026-04-24

In the Linux kernel

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a booby-trapped side door, not a broken front gate

CVE-2026-31635 is a length-check bug in the Linux kernel rxrpc subsystem's RxGK security path. In rxgk_verify_response(), an oversized RESPONSE authenticator can slip past validation and reach rxgk_decrypt_skb(), where the official kernel/NVD description says it can drive skb_to_sgvec() into BUG_ON(len) and crash the host. The affected upstream ranges published in the CNA/NVD data are Linux >=6.16 and before the fixes in 6.18.23, 6.19.13, and mainline 7.0; critically, the vulnerable code also depends on CONFIG_RXGK, a feature that LKDDb shows exists only in the 6.16+ era.

The vendor's 7.5/HIGH score is technically defensible in a vacuum because the packet is network-originated and authentication is not required, but it overstates enterprise-wide urgency. Real exploitation requires a reachable RxRPC server path, the niche AF_RXRPC/RXGK stack to be present, and a deployment actually using secure RxGK challenge/response; that is a tiny slice of a normal 10,000-host estate. Public PoC chatter keeps this above LOW, but for most enterprises this is not a broad internet-edge emergency.

"Vendor CVSS says internet crash bug; reality says niche RxRPC/RxGK server exposure on very new kernels only."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a real RxRPC target with nmap or custom UDP probing

The attacker first needs a host that is not just Linux, but actually exposing an RxRPC-backed service. In practice that usually means AFS-style service ports over UDP, with a server socket bound to a non-zero service ID as described in the kernel RxRPC documentation.
Conditions required:
  • Target runs Linux kernel in the affected upstream range
  • An RxRPC service is reachable over the network
  • Firewalling permits attacker-to-service UDP traffic
Where this breaks in practice:
  • AF_RXRPC is niche in enterprise fleets
  • Most hosts are not AFS servers and never bind RxRPC service sockets
  • Internet exposure is typically limited to specialized research/HPC/legacy AFS environments
Detection/coverage: External scanners can spot UDP listeners on AFS-associated ports, but commodity vuln scanners generally do not prove RxGK reachability or whether the vulnerable security class is enabled.
STEP 02

Drive the RxGK security handshake with a purpose-built client/PoC

The vulnerable function sits in the RxGK RESPONSE verification path, so the attacker must reach the secure connection setup flow rather than just send arbitrary junk to any UDP port. The kernel docs show the server sends a challenge and then expects a client response; public PoC material referenced by CISA ADP indicates researchers have implemented this path.
Conditions required:
  • Server is configured to permit secure RxRPC/RxGK negotiation
  • CONFIG_RXGK is present and active in the running kernel
  • The attacker can generate protocol-correct RxRPC traffic
Where this breaks in practice:
  • This is not a one-packet generic UDP crash against every Linux box
  • Protocol correctness and service configuration matter
  • CISA ADP marked exploitation as poc and automatable: no
Detection/coverage: Network IDS coverage is likely weak unless you already decode RxRPC/AFS traffic. Expect most detections to come from service logs, packet captures, or kernel crash telemetry rather than signature-based scanners.
STEP 03

Send the oversized RESPONSE authenticator

A crafted RESPONSE carries an auth_len that should be rejected if it exceeds the remaining packet bytes. Because the check is inverted, the kernel accepts an impossible length and passes the packet deeper into rxgk_decrypt_skb().
Conditions required:
  • Attacker can complete enough of the handshake to submit a RESPONSE
  • Target is running an unpatched vulnerable build
Where this breaks in practice:
  • Patched stable kernels reject the malformed length
  • Distro backports may already contain the fix even when the base version string looks close
Detection/coverage: If you have packet capture on the service segment, malformed RxRPC RESPONSE lengths are the best detection point. Version-only asset scanners can miss backports and config-dependent reachability.
STEP 04

Crash the kernel, and treat stronger-impact claims cautiously

The official CNA/NVD story ends in BUG_ON(len), which is a host-level availability hit. A public GitHub repo labeled dirtydecrypt claims a stronger page-cache-write primitive and possible privilege-escalation style impact in lab conditions, but the vendor CVSS and official description still model this as availability-only.
Conditions required:
  • Malformed packet reaches the vulnerable decrypt path
  • Kernel assertions are not avoided by the patched logic
Where this breaks in practice:
  • No KEV listing or verified broad in-the-wild exploitation
  • The stronger-impact claim is not reflected in the vendor vector
  • Blast radius is one host per vulnerable service instance, not a fleet-wide pre-auth domain takeover
Detection/coverage: You will most reliably see this through kernel panic/oops telemetry, crash dumps, or abrupt service/node loss. EDR is usually too late once the kernel trips BUG_ON().
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo verified active exploitation found in primary sources reviewed, and the CVE is not present in CISA KEV. That is a meaningful downward pressure versus the raw network CVSS.
PoC availabilityYes. CISA ADP references a public GitHub repo: v12-security/pocs/dirtydecrypt. CISA ADP's SSVC metadata says Exploitation: poc and Automatable: no.
EPSSUser-supplied EPSS is 0.00038, which is extremely low. I could not verify the exact percentile from a primary EPSS result page during this assessment, but the score itself is consistent with low observed exploitation likelihood.
KEV statusNot KEV-listed in the CISA Known Exploited Vulnerabilities Catalog. No KEV due date applies.
CVSS vector reality checkVendor vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The AV:N/PR:N piece is true only after you assume a reachable RxRPC service using the vulnerable RxGK path; that assumption does not hold for most enterprise Linux hosts.
Affected upstream versionsCNA/NVD data marks upstream Linux >=6.16 as affected, with unaffected cutoffs at 6.18.23, 6.19.13, and mainline 7.0. LKDDb also shows CONFIG_RXGK exists only in the 6.16+ generation, which sharply narrows population.
Fixed versions and distro notesUpstream fixes land at 6.18.23, 6.19.13, and 7.0. Ubuntu's tracker shows many mainstream LTS kernel lines as Not affected or Not in release; Amazon Linux reports AL2 and AL2023 kernel/kernel6.12 as Not Affected, while AL2023 kernel6.18 was Pending Fix on the advisory page reviewed.
Exposure populationThis is an AFS/RxRPC problem, not a generic Linux networking problem. Kernel docs and the AFS assigned-number registry tie common deployments to AFS/Rx service ports such as UDP 7000 and 7002-7009; I did not recover authoritative GreyNoise/Censys/Shodan counts showing broad internet exposure, which itself is a signal that this is niche.
Disclosure dateThe CVE was published on 2026-04-24 in NVD/OpenCVE/CNA data.
Reporting / provenanceThe official record comes from the Linux kernel CNA (kernel.org). Public exploit material attributes dirtydecrypt discovery to Aaron Esau / V12 in the GitHub README, but that stronger-impact narrative is not fully mirrored by the vendor CVSS.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive factor is reachable population: this bug only matters on hosts that both ship the very new RXGK feature set and actually expose an RxRPC server path. That turns a scary-looking network CVSS into a niche-service kernel bug for most enterprises, even though the per-host impact can be ugly where the service is real.

HIGH Affected upstream version range and fix versions
HIGH Need for RxRPC/RxGK-specific deployment conditions
MEDIUM Final impact beyond DoS, because public PoC claims exceed the official vendor vector

Why this verdict

  • Vendor baseline starts at 7.5/HIGH because the malformed input is network-originated and the official CVSS assumes no auth and no user interaction.
  • First downgrade: affected code is unusually narrow. CONFIG_RXGK exists only in the 6.16+ line, so huge swaths of enterprise Linux kernels never even contain this feature path.
  • Second downgrade: attacker position is 'unauthenticated remote' only if a rare service is reachable. In real fleets, requiring an exposed RxRPC/AFS server collapses the reachable population far below what AV:N normally implies.
  • Third downgrade: modern estates rarely run this at the edge. Most Linux servers behind NGFWs, cloud security groups, and standard build baselines are not listening for RxRPC service traffic at all.
  • Partial upward pressure remains because there is a public PoC trail and the bug lives in the kernel, where successful triggering can crash a node and create outsized operational pain on the few systems that do run it.

Why not higher?

I am not keeping this at HIGH because the attack path depends on a specialized service stack rather than broad Linux reachability. No KEV listing, no verified widespread exploitation, tiny EPSS, and CISA ADP's automatable: no all argue against fleet-wide emergency treatment.

Why not lower?

I am not dropping this to LOW because the vulnerable code is in the kernel and public PoC material exists. If you actually operate RxRPC/RxGK-backed AFS services, this moves from obscure to materially dangerous very quickly, and a single crash on storage or auth-adjacent infrastructure can hurt.

05 · Compensating Control

What to do — in priority order.

  1. Inventory rxrpc and rxgk now — Identify where the modules are built or loaded and where AFS/RxRPC services are actually listening. For a MEDIUM verdict there is no noisgate mitigation SLA, so do this as normal hardening and scoping work rather than as an emergency fleet action.
  2. Disable or blacklist unused rxrpc/rxgk — If the host is not supposed to provide AFS/RxRPC services, remove the attack path entirely by preventing module load or excluding the feature from your image. With no mitigation SLA for MEDIUM, fold this into the next hardening cycle and image refresh.
  3. Restrict UDP access to AFS/Rx service ports — Apply host firewall, security group, and network ACL restrictions so only expected peers can reach UDP ports used by AFS/RxRPC services. That shrinks the already-small exposed population further while you validate where patches/backports landed.
  4. Watch for kernel panic and RxRPC anomalies — Route dmesg, journald, crash dump, and node reboot telemetry into your SIEM for any host that runs AFS/RxRPC. This won't stop exploitation, but it gives you the fastest confirmation that a service node is being probed or has already faulted.
What doesn't work
  • Generic EDR does not meaningfully prevent a malformed packet from driving a kernel BUG_ON() path; it may only see the aftermath.
  • A WAF is irrelevant because this is not HTTP or reverse-proxy traffic.
  • Relying on CVSS-only prioritization overstates urgency across the estate because it ignores the RXGK feature gate and the tiny deployment population.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host itself as root or with sudo, because it needs local kernel/config/module visibility. Save as check-cve-2026-31635.sh and run sudo bash check-cve-2026-31635.sh; it prints VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2026-31635.sh
# Determine likely exposure to CVE-2026-31635 on a Linux host.
# Logic:
#   - CVE affects upstream kernels >= 6.16 before 6.18.23 / 6.19.13 / 7.0
#   - Vulnerable path requires CONFIG_AF_RXRPC and CONFIG_RXGK
#   - Distro backports can make version-only checks unreliable, so ambiguous cases return UNKNOWN
# Exit codes:
#   0 = PATCHED / NOT AFFECTED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

say() { printf '%s\n' "$*"; }

KREL="$(uname -r)"
KBASE="$(printf '%s' "$KREL" | sed -E 's/^([0-9]+\.[0-9]+\.[0-9]+).*/\1/')"

verlt() { [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]; }
verlte() { [ "$1" = "$2" ] || verlt "$1" "$2"; }
vergt() { [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ] && [ "$1" != "$2" ]; }
vergte() { [ "$1" = "$2" ] || vergt "$1" "$2"; }

get_cfg() {
  local key="$1"
  local src=""
  if [ -r /proc/config.gz ]; then
    src="/proc/config.gz"
    zgrep -E "^${key}=" /proc/config.gz 2>/dev/null | head -n1
    return
  fi
  if [ -r "/boot/config-$KREL" ]; then
    src="/boot/config-$KREL"
    grep -E "^${key}=" "/boot/config-$KREL" 2>/dev/null | head -n1
    return
  fi
  return 1
}

cfg_rxrpc="$(get_cfg CONFIG_AF_RXRPC || true)"
cfg_rxgk="$(get_cfg CONFIG_RXGK || true)"

have_rxrpc="unknown"
have_rxgk="unknown"

case "$cfg_rxrpc" in
  CONFIG_AF_RXRPC=y|CONFIG_AF_RXRPC=m) have_rxrpc="yes" ;;
  CONFIG_AF_RXRPC=n) have_rxrpc="no" ;;
  "") have_rxrpc="unknown" ;;
esac

case "$cfg_rxgk" in
  CONFIG_RXGK=y|CONFIG_RXGK=m) have_rxgk="yes" ;;
  CONFIG_RXGK=n) have_rxgk="no" ;;
  "") have_rxgk="unknown" ;;
esac

# Quick not-affected cases
if verlt "$KBASE" "6.16.0"; then
  say "PATCHED"
  say "Reason: upstream affected range starts at 6.16, and this host is running $KREL"
  exit 0
fi

if [ "$have_rxrpc" = "no" ] || [ "$have_rxgk" = "no" ]; then
  say "PATCHED"
  say "Reason: required kernel feature path is not enabled (AF_RXRPC=$have_rxrpc, RXGK=$have_rxgk)"
  exit 0
fi

# Upstream fixed versions
if vergte "$KBASE" "7.0.0"; then
  say "PATCHED"
  say "Reason: mainline 7.0 and later include the upstream fix"
  exit 0
fi

# 6.18.x branch fix point
if vergte "$KBASE" "6.18.23" && verlt "$KBASE" "6.19.0"; then
  say "PATCHED"
  say "Reason: 6.18.23+ includes the stable fix point"
  exit 0
fi

# 6.19.x branch fix point
if vergte "$KBASE" "6.19.13" && verlt "$KBASE" "7.0.0"; then
  say "PATCHED"
  say "Reason: 6.19.13+ includes the stable fix point"
  exit 0
fi

# Likely vulnerable upstream windows
likely_vuln="no"
if vergte "$KBASE" "6.16.0" && verlt "$KBASE" "6.18.23"; then
  likely_vuln="yes"
fi
if vergte "$KBASE" "6.19.0" && verlt "$KBASE" "6.19.13"; then
  likely_vuln="yes"
fi

# Gather practical reachability clues
listening="no"
if command -v ss >/dev/null 2>&1; then
  if ss -H -u -l -n 2>/dev/null | awk '{print $5}' | grep -Eq ':(7000|7001|7002|7003|7004|7005|7006|7007|7008|7009|7020|7021|7022|7023)$'; then
    listening="yes"
  fi
fi

loaded_rxrpc="no"
loaded_rxgk="no"
if lsmod 2>/dev/null | awk '{print $1}' | grep -qx 'rxrpc'; then loaded_rxrpc="yes"; fi
if lsmod 2>/dev/null | awk '{print $1}' | grep -qx 'rxgk'; then loaded_rxgk="yes"; fi

# Distro kernels may backport fixes without changing the base version enough.
# If the host looks like a vendor kernel with a potentially vulnerable base version, be conservative.
vendor_kernel="no"
printf '%s' "$KREL" | grep -Eq '(amzn|el[0-9]|uek|azure|aws|gcp|generic|lowlatency|kali|arch|fc[0-9]|deb[0-9]|ubuntu)' && vendor_kernel="yes"

if [ "$likely_vuln" = "yes" ]; then
  if [ "$have_rxrpc" = "yes" ] && [ "$have_rxgk" = "yes" ]; then
    if [ "$vendor_kernel" = "yes" ]; then
      say "UNKNOWN"
      say "Reason: kernel base version $KBASE is in an upstream vulnerable window and required features are enabled, but distro backports may already have fixed $KREL"
      say "Clues: RXRPC loaded=$loaded_rxrpc, RXGK loaded=$loaded_rxgk, AFS/RxRPC UDP listener seen=$listening"
      exit 2
    else
      say "VULNERABLE"
      say "Reason: upstream version $KREL falls in a published affected window and required features are enabled"
      say "Clues: RXRPC loaded=$loaded_rxrpc, RXGK loaded=$loaded_rxgk, AFS/RxRPC UDP listener seen=$listening"
      exit 1
    fi
  fi

  say "UNKNOWN"
  say "Reason: upstream version is in range, but kernel config visibility is incomplete (AF_RXRPC=$have_rxrpc, RXGK=$have_rxgk)"
  exit 2
fi

say "UNKNOWN"
say "Reason: unable to map $KREL cleanly to the published upstream windows/fix points"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not spray this across every Linux host just because the vendor says AV:N. First, query your fleet for kernels in the 6.16+ generation and then narrow hard to systems with rxrpc/rxgk present or AFS/RxRPC service exposure; for most enterprises that list will be very short. Because this is a MEDIUM reassessment and there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but any host you confirm is an exposed RxRPC/RxGK server should get immediate configuration review and network restriction while you patch. Use the noisgate remediation SLA to land the vendor fix or validated distro backport within 365 days, and treat anything internet- or cross-segment-exposed as a locally accelerated exception even though the fleet-wide verdict stays MEDIUM.

Sources

  1. NVD CVE-2026-31635
  2. OpenCVE mirror of CNA/NVD record with affected versions and CISA ADP enrichment
  3. Linux kernel RxRPC documentation
  4. LKDDb / CONFIG_RXGK
  5. kernelconfig.io / CONFIG_AF_RXRPC
  6. Ubuntu security tracker for CVE-2026-31635
  7. Amazon Linux Security Center advisory
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.