In the Linux kernel

CVE-2026-43494 is a Linux kernel local privilege-escalation bug in the net/rds zerocopy send path. When iov_iter_get_pages2() fails inside rds_message_zcopy_from_user(), previously pinned pages are released, but op_nents is not reset; later cleanup can free those pages again. Upstream tracking puts the affected ranges at 4.17.0 through <6.6.141, 6.7.0 through <6.12.91, 6.13.0 through <6.18.33, and 6.19.0 through <7.0.10.

The vendor HIGH is technically defensible if you assume an attacker already has low-privileged code execution on a host with reachable RDS support and can weaponize the bug into root. In real enterprise fleets, though, this lands later in the kill chain: it is local-only, depends on the relatively niche rds subsystem, and multiple distributions reduce exposure by packaging it separately or blacklisting it. Public PoC availability keeps this from being low, but it does not justify treating it like an internet-facing emergency.

Why this verdict

• Downgrade for attacker position: vendor 7.8 assumes a low-priv local attacker already exists on the host. That means this CVE is mostly a *post-compromise amplifier*, not a first-entry risk.
• Downgrade for reachable population: the bug lives in the net/rds zerocopy send path, not a mainstream kernel path every workload hits. If rds is absent, never loaded, or blacklisted, the practical attack surface collapses.
• Partial upgrade for exploit maturity: a public PinTheft PoC shows this is not just a crash or theoretical refcount bug; it can be driven to root when the environment lines up.
• Downgrade for threat evidence: no KEV listing, no reviewed public campaign evidence, and a very low EPSS all argue against emergency fleet-wide treatment.

Why not higher?

Because every serious step in the chain narrows the blast radius. The attacker needs local execution first, then a host where RDS is actually reachable, then enough exploit reliability to convert a kernel memory-management bug into root; that is materially different from an unauthenticated remote or broadly exposed kernel flaw.

Why not lower?

Because the end state is still root on the host, and public weaponization exists. On shared Linux systems, CI runners, multi-user bastions, and dense container nodes, a local LPE with a public chain is not housekeeping noise.

1. Blacklist or unload rds — If your workloads do not use RDS, remove the reachable attack surface by blacklisting rds and unloading it where operationally safe. For a MEDIUM verdict there is no mitigation SLA — apply this opportunistically on higher-risk shared hosts, then complete vendor patching within the 365-day remediation window.
2. Block AF_RDS and risky local primitives for untrusted workloads — Use seccomp, container runtime policies, LSMs, or host hardening to deny AF_RDS socket creation and restrict io_uring where that fits your platform model. There is no mitigation SLA for MEDIUM, so treat this as targeted risk reduction on developer workstations, CI, VDI, and multi-tenant nodes.
3. Prioritize shared-user and container-dense Linux nodes — The business risk is much higher where low-privileged users or untrusted code already coexist on the same kernel. There is no mitigation SLA for MEDIUM, but these systems deserve earlier patch sequencing inside the 365-day remediation window.

Run this on the target Linux host as a local auditor or via your fleet agent. Invoke it with bash cve-2026-43494-check.sh; root is not strictly required, but root improves access to kernel config files and module state. The script reports VULNERABLE, PATCHED, or UNKNOWN and is conservative around distro backports.

#!/usr/bin/env bash
# CVE-2026-43494 exposure check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail

KVER="$(uname -r)"
BASE="${KVER%%-*}"
SUFFIX="${KVER#${BASE}}"
STATUS="UNKNOWN"
REASON=""

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

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

in_range() {
  local v="$1" lo="$2" hi="$3"
  ver_ge "$v" "$lo" && ver_lt "$v" "$hi"
}

is_affected_upstream() {
  local v="$1"
  in_range "$v" "4.17.0" "6.6.141" || \
  in_range "$v" "6.7.0" "6.12.91" || \
  in_range "$v" "6.13.0" "6.18.33" || \
  in_range "$v" "6.19.0" "7.0.10"
}

CFG_LINE=""
if [ -r "/proc/config.gz" ] && command -v zgrep >/dev/null 2>&1; then
  CFG_LINE="$(zgrep '^CONFIG_RDS=' /proc/config.gz 2>/dev/null || true)"
elif [ -r "/boot/config-${KVER}" ]; then
  CFG_LINE="$(grep '^CONFIG_RDS=' "/boot/config-${KVER}" 2>/dev/null || true)"
fi

RDS_CFG="unknown"
case "$CFG_LINE" in
  CONFIG_RDS=y) RDS_CFG="built-in" ;;
  CONFIG_RDS=m) RDS_CFG="module" ;;
  CONFIG_RDS=n|"") RDS_CFG="absent" ;;
  *) RDS_CFG="unknown" ;;
esac

RDS_LOADED="no"
if command -v lsmod >/dev/null 2>&1 && lsmod | awk '{print $1}' | grep -qx 'rds'; then
  RDS_LOADED="yes"
fi

RDS_PRESENT="no"
if [ "$RDS_CFG" = "built-in" ] || [ "$RDS_CFG" = "module" ]; then
  RDS_PRESENT="yes"
elif command -v modinfo >/dev/null 2>&1 && modinfo rds >/dev/null 2>&1; then
  RDS_PRESENT="yes"
fi

BLACKLISTED="no"
if grep -RqsE '^[[:space:]]*blacklist[[:space:]]+rds([[:space:]]|$)' /etc/modprobe.d /usr/lib/modprobe.d /lib/modprobe.d 2>/dev/null; then
  BLACKLISTED="yes"
fi

if [ "$RDS_CFG" = "absent" ] || { [ "$RDS_PRESENT" = "no" ] && [ "$RDS_LOADED" = "no" ]; }; then
  STATUS="PATCHED"
  REASON="RDS support not present on this host; vulnerable subsystem is not reachable here."
elif ! is_affected_upstream "$BASE"; then
  STATUS="PATCHED"
  REASON="Kernel base version ${BASE} is outside the published upstream affected ranges."
else
  # Distro kernels often backport fixes without changing the base version.
  if [ -n "$SUFFIX" ]; then
    if [ "$BLACKLISTED" = "yes" ] && [ "$RDS_LOADED" = "no" ]; then
      STATUS="UNKNOWN"
      REASON="Kernel base ${BASE} falls in an affected upstream range, but this appears to be a distro kernel with possible backports; RDS is blacklisted and not loaded, so current risk is mitigated but patch state is not provable offline."
    else
      STATUS="UNKNOWN"
      REASON="Kernel base ${BASE} falls in an affected upstream range, but distro backports cannot be validated from uname alone. Check vendor advisory/package changelog for CVE-2026-43494."
    fi
  else
    if [ "$BLACKLISTED" = "yes" ] && [ "$RDS_LOADED" = "no" ]; then
      STATUS="UNKNOWN"
      REASON="Mainline-style kernel base ${BASE} is in an affected range, but RDS is currently blacklisted and not loaded; host is mitigated, patch state still unknown."
    else
      STATUS="VULNERABLE"
      REASON="Mainline-style kernel base ${BASE} is in a published affected range and RDS is present/reachable."
    fi
  fi
fi

echo "${STATUS}: ${REASON}"
case "$STATUS" in
  PATCHED) exit 0 ;;
  VULNERABLE) exit 1 ;;
  *) exit 2 ;;
esac

Sources

1. OSV record for CVE-2026-43494
2. oss-security thread linking CVE-2026-43494 to PinTheft
3. Linux kernel RDS documentation
4. Linux Kernel Driver DataBase: CONFIG_RDS
5. Red Hat Security Data API search
6. SUSE CVE page
7. Debian DSA-6305-1
8. CISA Known Exploited Vulnerabilities Catalog