In the Linux kernel

pcrypt is the Linux kernel's parallel crypto wrapper, used to run crypto work in kernel threads. The fix for CVE-2026-43493 corrects how MAY_BACKLOG async AEAD requests handle -EBUSY and stray -EINPROGRESS callbacks; without it, request completion state can be mishandled. The bug is in crypto/pcrypt.c, was reported by Yiming Qian, and upstream fixed it in commit 915b692e6cb723aac658c25eb82c58fd81235110, with backports flowing into stable branches and distro kernels.

The vendor's 9.8 / AV:N / PR:N label does not match how this lands in enterprise reality. pcrypt is not a network service, the vulnerable path depends on CONFIG_CRYPTO_PCRYPT plus an async AEAD workload that actually hits MAY_BACKLOG, and public evidence so far points to availability/stability fallout rather than straightforward remote code execution. Ubuntu tags it *Medium* and SUSE rescored it as a local, availability-heavy issue, which is much closer to the truth.

Why this verdict

• Vendor vector overstates reachability — AV:N/PR:N assumes an attacker can hit this bug like a remotely exposed service, but pcrypt is a kernel helper path, not a socket-facing daemon.
• Module + workload gating cuts the exposed population hard — you need CONFIG_CRYPTO_PCRYPT plus an async AEAD workload that actually reaches the MAY_BACKLOG branch, which many enterprise Linux hosts never do.
• Exploit intelligence is quiet — no KEV listing, no public exploitation evidence, no public PoC, and an EPSS around 0.00062 are all downward pressure from the vendor baseline.
• Likely blast radius is host-local availability — the public fix narrative is about incorrect async completion/error handling, not a documented path to data theft or reliable privilege escalation.
• Modern controls indirectly help — EDR, container isolation, least-privilege host access, and reducing arbitrary code execution on Linux nodes all make the first prerequisite harder, which matters because this is effectively post-initial-access in most real environments.

Why not higher?

There is no credible evidence that unauthenticated remote attackers can directly reach this code path across normal enterprise fleets. The missing pieces are a public exploit chain, a pre-auth network entry point, and any meaningful in-the-wild signal; without those, HIGH or CRITICAL would be vendor-score cargo culting.

Why not lower?

It still sits in the kernel, and when the affected path is present the impact can be system instability on important Linux infrastructure. On shared compute, crypto-heavy appliances, or specialized hosts that actually load and use pcrypt, the operational consequence is real enough that this should stay above pure backlog noise.

1. Inventory pcrypt usage — Check whether pcrypt is built, loaded, or referenced anywhere in your fleet so you stop treating every Linux host as equally exposed. For a MEDIUM verdict there is no noisgate mitigation SLA; do this during normal patch-validation work and use it to target the actual subset before the remediation deadline.
2. Blacklist unused pcrypt — Where pcrypt is a loadable module and you confirm no dependency, blacklist or prevent loading to collapse the attack surface entirely. For MEDIUM, there is no mitigation SLA, so apply this as a hygiene control in the normal change window rather than as an emergency action.
3. Harden shared Linux execution — Prioritize least privilege, container isolation, and limiting arbitrary code execution on multi-tenant Linux systems, because the real attack chain usually starts with a foothold on the box. This is the most useful compensating control when a kernel bug is effectively post-initial-access.
4. Watch for crypto-path instability — Add alerting for unusual kernel crashes, soft lockups, or repeated crypto request failures on systems known to use kernel crypto heavily. It will not prevent the bug, but it shortens the time to identify the small set of actually exposed roles.

Run this on the target Linux host. Invoke it as bash verify-cve-2026-43493.sh or sudo bash verify-cve-2026-43493.sh; root is recommended so the script can read /proc/config.gz, /boot/config-*, and installed kernel source/header trees. The script prefers direct source/header inspection for the actual fix logic and falls back to conservative version heuristics, returning VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# verify-cve-2026-43493.sh
# Check Linux kernel for CVE-2026-43493 (crypto: pcrypt - Fix handling of MAY_BACKLOG requests)
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

KREL="$(uname -r)"
BASE="${KREL%%-*}"

have_cmd() { command -v "$1" >/dev/null 2>&1; }

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

is_fixed_by_version() {
  local v="$1"
  case "$v" in
    5.10.*) ver_lt "$v" "5.10.258" && return 1 || return 0 ;;
    5.15.*) ver_lt "$v" "5.15.209" && return 1 || return 0 ;;
    6.1.*)  ver_lt "$v" "6.1.175"  && return 1 || return 0 ;;
    6.6.*)  ver_lt "$v" "6.6.140"  && return 1 || return 0 ;;
    6.12.*) ver_lt "$v" "6.12.86"  && return 1 || return 0 ;;
    7.0.*)  ver_lt "$v" "7.0.4"    && return 1 || return 0 ;;
    7.1.*)  return 0 ;;
    *)      return 2 ;;
  esac
}

check_source_file() {
  local f="$1"
  [ -r "$f" ] || return 2

  if grep -Eq 'if \(err == -EINPROGRESS\)' "$f" && \
     grep -Eq 'ret == -EINPROGRESS \|\| ret == -EBUSY' "$f"; then
    return 0
  fi

  if grep -Eq 'ret == -EINPROGRESS\)' "$f" && \
     ! grep -Eq 'ret == -EINPROGRESS \|\| ret == -EBUSY' "$f"; then
    return 1
  fi

  return 2
}

read_kernel_config() {
  if [ -r /proc/config.gz ] && have_cmd zgrep; then
    zgrep -E '^CONFIG_CRYPTO_PCRYPT=' /proc/config.gz 2>/dev/null | tail -n1
    return
  fi
  if [ -r "/boot/config-$KREL" ]; then
    grep -E '^CONFIG_CRYPTO_PCRYPT=' "/boot/config-$KREL" 2>/dev/null | tail -n1
    return
  fi
  echo ""
}

PCONF="$(read_kernel_config)"
PMOD="unknown"
case "$PCONF" in
  CONFIG_CRYPTO_PCRYPT=y) PMOD="builtin" ;;
  CONFIG_CRYPTO_PCRYPT=m) PMOD="module" ;;
  CONFIG_CRYPTO_PCRYPT=n) PMOD="disabled" ;;
  *) PMOD="unknown" ;;
esac

# 1) Best check: inspect installed source/header trees for the fixed logic.
CANDIDATES=(
  "/lib/modules/$KREL/source/crypto/pcrypt.c"
  "/lib/modules/$KREL/build/crypto/pcrypt.c"
  "/usr/src/linux-headers-$KREL/crypto/pcrypt.c"
  "/usr/src/kernels/$KREL/crypto/pcrypt.c"
)

for f in "${CANDIDATES[@]}"; do
  check_source_file "$f"
  rc=$?
  if [ $rc -eq 0 ]; then
    echo "PATCHED: fix logic present in $f (CVE-2026-43493)"
    exit 0
  elif [ $rc -eq 1 ]; then
    if [ "$PMOD" = "disabled" ]; then
      echo "PATCHED: vulnerable code pattern in source tree, but CONFIG_CRYPTO_PCRYPT is disabled"
      exit 0
    fi
    echo "VULNERABLE: unfixed pcrypt logic found in $f"
    exit 1
  fi
done

# 2) Secondary check: loaded module binary presence.
if lsmod 2>/dev/null | awk '{print $1}' | grep -qx 'pcrypt'; then
  PLOADED="yes"
else
  PLOADED="no"
fi

# 3) Fallback: upstream-style version heuristic.
is_fixed_by_version "$BASE"
rc=$?
if [ $rc -eq 0 ]; then
  echo "PATCHED: kernel base version $BASE is at or above a known upstream fixed branch threshold; verify distro backports if this is a vendor kernel"
  exit 0
elif [ $rc -eq 1 ]; then
  if [ "$PMOD" = "disabled" ]; then
    echo "PATCHED: kernel version is in an affected upstream range, but CONFIG_CRYPTO_PCRYPT is disabled"
    exit 0
  fi
  echo "VULNERABLE: kernel base version $BASE is below known upstream fixed thresholds and pcrypt is $PMOD (loaded=$PLOADED)"
  exit 1
fi

# 4) Unknown branch or vendor backport ambiguity.
echo "UNKNOWN: cannot prove fix state for kernel $KREL. pcrypt_config=$PMOD loaded=$PLOADED. Check vendor advisory/changelog or install matching kernel headers/source and rerun."
exit 2

Sources

1. NVD entry
2. Upstream stable patch mail (6.12 review)
3. Debian security tracker
4. SUSE CVE page
5. Ubuntu CVE search result
6. Docker Scout advisory page
7. CISA KEV catalog
8. FIRST EPSS API documentation