In the Linux kernel

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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.

#!/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

Sources

1. NVD CVE-2026-43500
2. GitHub PoC and technical notes - V4bel/dirtyfrag
3. Red Hat Dirty Frag bulletin RHSB-2026-003
4. Amazon Linux Security Center CVE-2026-43500
5. Red Hat Bugzilla 2468273 for CVE-2026-43500
6. CISA Known Exploited Vulnerabilities Catalog
7. Linux CVE announce archive index