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.
4 steps from start to impact.
Find a real RxRPC target with nmap or custom UDP probing
- Target runs Linux kernel in the affected upstream range
- An RxRPC service is reachable over the network
- Firewalling permits attacker-to-service UDP traffic
AF_RXRPCis 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
Drive the RxGK security handshake with a purpose-built client/PoC
- Server is configured to permit secure RxRPC/RxGK negotiation
CONFIG_RXGKis present and active in the running kernel- The attacker can generate protocol-correct RxRPC traffic
- This is not a one-packet generic UDP crash against every Linux box
- Protocol correctness and service configuration matter
- CISA ADP marked exploitation as
pocandautomatable: no
Send the oversized RESPONSE authenticator
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().- Attacker can complete enough of the handshake to submit a RESPONSE
- Target is running an unpatched vulnerable build
- Patched stable kernels reject the malformed length
- Distro backports may already contain the fix even when the base version string looks close
Crash the kernel, and treat stronger-impact claims cautiously
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.- Malformed packet reaches the vulnerable decrypt path
- Kernel assertions are not avoided by the patched logic
- 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
BUG_ON().The supporting signals.
| In-the-wild status | No 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 availability | Yes. CISA ADP references a public GitHub repo: v12-security/pocs/dirtydecrypt. CISA ADP's SSVC metadata says Exploitation: poc and Automatable: no. |
| EPSS | User-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 status | Not KEV-listed in the CISA Known Exploited Vulnerabilities Catalog. No KEV due date applies. |
| CVSS vector reality check | Vendor 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 versions | CNA/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 notes | Upstream 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 population | This 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 date | The CVE was published on 2026-04-24 in NVD/OpenCVE/CNA data. |
| Reporting / provenance | The 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. |
noisgate verdict.
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.
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_RXGKexists 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:Nnormally 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.
What to do — in priority order.
- Inventory
rxrpcandrxgknow — 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. - 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. - 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.
- 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.
- 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
RXGKfeature gate and the tiny deployment population.
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.
#!/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
If you remember one thing.
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
- NVD CVE-2026-31635
- OpenCVE mirror of CNA/NVD record with affected versions and CISA ADP enrichment
- Linux kernel RxRPC documentation
- LKDDb / CONFIG_RXGK
- kernelconfig.io / CONFIG_AF_RXRPC
- Ubuntu security tracker for CVE-2026-31635
- Amazon Linux Security Center advisory
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.