CVE-2026-43500 · Linux kernel RxRPC shared-fragment packet handling out-of-bounds…

01 · The Real Story

This is a spare key hidden inside the building, not a front-door lock that fails from the street

CVE-2026-43500 is a Linux kernel memory-safety flaw in the rxrpc networking subsystem. In affected kernels, DATA and RESPONSE packet handling only forced a private skb copy when skb_cloned() was true, missing cases where paged fragments were still externally shared; that can steer in-place crypto over shared frag pages and produce a page-cache write primitive. NVD lists affected upstream kernels from 5.3 up to but excluding 6.18.29, and from 6.19 up to but excluding 7.0.6; the public PoC research further traces the vulnerable logic to commit 2dc334f1a63a and the mainline fix to aa54b1d27fe0.

The vendor's HIGH 7.8 is technically fair in a lab because successful exploitation ends in root-level impact. In real enterprise operations, though, this is post-initial-access: the attacker already needs local code execution with low privileges, and the host also needs RxRPC support enabled or available. That attacker-position requirement, plus the fact that rxrpc.ko is not present or loaded on many fleets, pushes this down to a MEDIUM prioritization item for most 10,000-host environments.

"Serious post-compromise root bug, but the need for local access plus RxRPC narrows the real enterprise blast radius."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on the box first

The attacker needs local unprivileged code execution on the target Linux host before this CVE matters at all. In practice that means a compromised developer account, CI worker foothold, container breakout precursor, or any other already-won shell; the public weaponized reference is the V4bel/dirtyfrag PoC, but it is not a remote entry tool by itself.

Conditions required:

Authenticated or otherwise obtained local code execution
Ability to run native code on the host

Where this breaks in practice:

This is not reachable from the internet as a first hop
EDR, application allowlisting, and container isolation often stop commodity post-exploitation before an LPE gets attempted

Detection/coverage: Most network scanners will miss this entirely because AV:L is the real gate. Host telemetry that records local compiler execution, unusual writes to setuid targets, or exploit-like page-cache abuse is more relevant than vuln scanning.

STEP 02

Need the RxRPC code path present

The exploit path only exists if the target kernel includes RxRPC support (CONFIG_RXRPC=y/m) and the vulnerable logic is present. The public research explicitly notes rxrpc.ko is not included in most distributions, while Ubuntu is called out as a common case where it is loaded by default, which sharply narrows real exposure compared with a generic 'Linux kernel' label.

Conditions required:

Kernel version in affected upstream range or an equivalent vulnerable backport
RxRPC enabled as built-in or module

Where this breaks in practice:

Many enterprise hosts do not use AFS/RxRPC at all
Some vendor kernels are backported and not vulnerable even when the version string looks older

Detection/coverage: Simple version-only scanners will over-report. Good coverage needs both kernel-package intelligence and a host-side check for CONFIG_RXRPC or an installed rxrpc module.

STEP 03

Trigger shared-frag corruption with the public PoC

Using the dirtyfrag PoC, the attacker drives the RxRPC packet path so shared paged fragments are not unshared before crypto processing. The missing unshare on skb_has_frag_list() or skb_has_shared_frag() lets the in-place decrypt path operate on shared frag pages, creating the write primitive described by kernel.org and NVD.

Conditions required:

Ability to execute the PoC locally
Suitable vulnerable skb/frag handling path reachable on the host

Where this breaks in practice:

The exploit is deterministic by researcher claims, but it is still kernel-path-specific and not universally portable across every distro packaging choice
Kernel hardening and workload confinement can make post-root objectives noisier even if the primitive lands

Detection/coverage: There is public exploit code (V4bel/dirtyfrag), so detection engineering can key on the repo's build/run pattern, suspicious gcc activity, and forensic signs of transient page-cache corruption.

STEP 04

Overwrite privileged page-cache content and pivot to root

Once the primitive is achieved, the attacker can corrupt page-cache-backed content for privileged binaries or files and then execute the modified target to gain root. That is why the impact remains material even after downgrade pressure: the blast radius on a single affected host is full local privilege escalation.

Conditions required:

Successful write primitive
A suitable privileged target on disk/page cache

Where this breaks in practice:

This compromises the host, not the entire fleet, unless the adversary can repeat it broadly
Modern EDR, file-integrity monitoring, or rapid host rebuild practices can limit dwell time after escalation

Detection/coverage: Kernel crashes are not required by the public research, so absence of a panic is not safety. Watch for anomalous execution of recently cached setuid binaries, unexplained privilege transitions, and immediate follow-on persistence actions.

03 · Compensating Control

Disable rxrpc where unused — Blacklist and unload the rxrpc module on systems that do not require AFS/RxRPC. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is still the best temporary control for shared-user Linux systems, CI runners, and Ubuntu estates where local untrusted code is realistic.

Prioritize multi-user Linux pools — Re-rank hosts by *who can run code there*, not by raw CVSS. Jump boxes, research clusters, developer workstations, CI/CD builders, and dense container workers should get first attention because local unprivileged execution is common there even though there is no noisgate mitigation SLA for MEDIUM.

Reduce arbitrary local code execution — Tighten shell access, rootless build pathways, and ad-hoc compiler use on high-value Linux servers. This does not remove the kernel flaw, but it cuts off the prerequisite stage the attacker must already have before this CVE can be used, buying time inside the 365-day remediation window.

Add host-side detection for exploit staging — Monitor for suspicious compilation and execution of local kernel exploit tooling, unexpected writes involving setuid targets, and abrupt privilege transitions to root. Because this is a local LPE, host telemetry is more valuable than perimeter controls while you work through remediation.

What doesn't work

A WAF or edge reverse proxy does not help; the vulnerable path is local kernel code, not HTTP input.
External attack-surface scanners do not tell you much here; they cannot determine whether a host both has a vulnerable kernel and has CONFIG_RXRPC enabled in a usable way.
MFA is good hygiene but irrelevant to exploit mechanics after a local foothold already exists.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No evidence of CISA KEV listing and no authoritative public campaign reporting found during this review. Risk is driven by public weaponization, not confirmed broad active exploitation.
Proof-of-concept availability	Yes. Public PoC in `V4bel/dirtyfrag`; NVD also references that repo. The README describes it as a deterministic local root chain and shows a one-line build/run path.
EPSS	User-supplied EPSS: `0.40266`. Secondary trackers place it around the 79th percentile; treat that as directional rather than primary-source authoritative.
KEV status	Not listed in the CISA Known Exploited Vulnerabilities Catalog as reviewed.
CVSS vector	`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = easy once local code execution exists, but strictly local and already post-compromise.
Affected versions	NVD maps affected upstream kernels as `5.3` to `<6.18.29` and `6.19` to `<7.0.6`. The PoC research traces the vulnerable RxRPC logic to `2dc334f1a63a` and the mainline fix to `aa54b1d27fe0`.
Fixed versions / backports	Upstream fixed by mainline commit `aa54b1d27fe0`; stable fix references include `6.18.29` and `7.0.6`. Distro state is mixed: Amazon Linux 2023 not affected, Amazon Linux 2 kernel-5.4/5.10 extras pending fix, and Red Hat's Dirty Frag bulletin says the RxRPC variant does not affect Red Hat products.
Exposure population	This is the big downgrade lever: the public research says `rxrpc.ko` is not included in most distributions, with Ubuntu highlighted as a common exception where it is loaded by default.
Scanning / exposure data	Internet scan data is a poor proxy here. This is a local kernel LPE, so Shodan/Censys/GreyNoise-style external exposure counts do not meaningfully represent exploitability; host inventory and kernel config data matter more than perimeter telemetry.
Disclosure / reporter	Publicly disclosed `2026-05-11` in NVD; Red Hat Bugzilla shows report activity on `2026-05-08`. Public research credits Hyunwoo Kim (@v4bel).

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.1/10)

Why this verdict

Downgrade for attacker position: AV:L/PR:L means the attacker already has a foothold and authenticated execution on the target host; this is post-initial-access, not an entry vector.
Downgrade for exposure population: exploitation depends on RxRPC being enabled or available, and the public research states rxrpc.ko is not included in most distributions; that sharply narrows how many hosts in a large fleet are actually in scope.
Partial upward pressure for weaponization: there is a public PoC (V4bel/dirtyfrag), and the researcher describes the primitive as deterministic with high success, so this is not a purely theoretical kernel bug once the prerequisites line up.

Why not higher?

There is no verified KEV listing or authoritative public evidence of broad in-the-wild exploitation campaigns at review time. More importantly, needing local access plus a narrower-than-average kernel feature population means this does not create the fleet-wide emergency pressure you reserve for unauthenticated remote bugs or ubiquitous post-auth admin bypasses.

Why not lower?

Calling this LOW would understate the impact. If an attacker already has a shell on an affected host with RxRPC present, the end state is root-level control of that machine, and there is public exploit code to operationalize it.

06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host as root if possible, or as a user who can read /boot/config-* or /proc/config.gz. Invoke it as sudo bash ./check-cve-2026-43500.sh; it checks for upstream-vulnerable kernel ranges and whether RxRPC is enabled, then returns VULNERABLE, PATCHED, or UNKNOWN with an exit code.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-cve-2026-43500.sh
# Purpose: Assess likely exposure to CVE-2026-43500 on a Linux host.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

KREL="$(uname -r 2>/dev/null || true)"
if [[ -z "$KREL" ]]; then
  echo "UNKNOWN: unable to determine kernel release"
  exit 2
fi

BASE="${KREL%%-*}"
if [[ "$BASE" =~ rc[0-9]+$ ]]; then
  echo "UNKNOWN: release candidate kernel '$KREL' requires manual review"
  exit 2
fi

ver_lt() {
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" && "$1" != "$2" ]]
}

ver_le() {
  [[ "$1" == "$2" ]] || ver_lt "$1" "$2"
}

ver_ge() {
  ! ver_lt "$1" "$2"
}

# Upstream affected ranges from NVD:
#  - >= 5.3 and < 6.18.29
#  - >= 6.19 and < 7.0.6
UPSTREAM_VULN=0
if ver_ge "$BASE" "5.3" && ver_lt "$BASE" "6.18.29"; then
  UPSTREAM_VULN=1
elif ver_ge "$BASE" "6.19" && ver_lt "$BASE" "7.0.6"; then
  UPSTREAM_VULN=1
fi

# Detect likely distro backport cases where version-only checks are unreliable.
# These may still be patched even if the base version sorts into the vulnerable range.
BACKPORT_DISTRO=0
if [[ "$KREL" == *".el"* || "$KREL" == *"amzn"* || "$KREL" == *"suse"* || "$KREL" == *"generic"* || "$KREL" == *"azure"* || "$KREL" == *"aws"* ]]; then
  BACKPORT_DISTRO=1
fi

# Read kernel config if available.
CFG=""
if [[ -r /proc/config.gz ]]; then
  CFG="$(zgrep '^CONFIG_RXRPC=' /proc/config.gz 2>/dev/null || true)"
elif [[ -r "/boot/config-$KREL" ]]; then
  CFG="$(grep '^CONFIG_RXRPC=' "/boot/config-$KREL" 2>/dev/null || true)"
fi

RXRPC_STATE="unknown"
case "$CFG" in
  "CONFIG_RXRPC=y") RXRPC_STATE="builtin" ;;
  "CONFIG_RXRPC=m") RXRPC_STATE="module" ;;
  "CONFIG_RXRPC=n") RXRPC_STATE="disabled" ;;
  "")
    if command -v modinfo >/dev/null 2>&1 && modinfo rxrpc >/dev/null 2>&1; then
      RXRPC_STATE="module"
    elif [[ -d "/lib/modules/$KREL" ]] && find "/lib/modules/$KREL" -type f \( -name 'rxrpc.ko' -o -name 'rxrpc.ko.xz' -o -name 'rxrpc.ko.zst' \) 2>/dev/null | grep -q .; then
      RXRPC_STATE="module"
    fi
    ;;
esac

if [[ "$RXRPC_STATE" == "disabled" ]]; then
  echo "PATCHED: RxRPC support is disabled on this host (CONFIG_RXRPC=n)"
  exit 0
fi

if [[ $UPSTREAM_VULN -eq 0 ]]; then
  echo "PATCHED: kernel version '$KREL' is outside the known upstream vulnerable ranges"
  exit 0
fi

if [[ "$RXRPC_STATE" == "unknown" ]]; then
  echo "UNKNOWN: kernel '$KREL' falls in an upstream vulnerable range, but RxRPC enablement could not be determined"
  exit 2
fi

if [[ $BACKPORT_DISTRO -eq 1 ]]; then
  echo "UNKNOWN: '$KREL' is a distro/backport-style kernel; version sorting alone is not authoritative even though RxRPC is $RXRPC_STATE"
  exit 2
fi

echo "VULNERABLE: upstream-version kernel '$KREL' is in range and RxRPC is $RXRPC_STATE"
exit 1