In the Linux kernel

The kernel TLS (kTLS) offload path has a use-after-free in tls_decrypt_done when a userland reader issues a partial read while asynchronous decryption is still in-flight. The async completion path and the sync read path both operate on the same sk_buff/context, and the freeing order can leave a dangling pointer that later gets dereferenced or written. Affected kernels are essentially every mainline branch that carries the async kTLS rework — roughly >=5.1 through the pre-patch commits in 6.1.x/6.6.x/6.7.x LTS lines. Fix landed upstream in the Feb 2024 stable pushes (6.1.79, 6.6.18, 6.7.6 and later) and was backported into distro kernels (RHEL, Ubuntu, SUSE, Debian) over the following weeks.

Red Hat, SUSE and NVD all tag this HIGH / 7.8 with an AV:L/PR:L vector, which is the correct *ceiling* for a kernel UAF that could conceivably be shaped into LPE. But the vendor score does not price in the reachability gate: the offending path only fires when a process is actively using TLS_RX kTLS AND triggers async decryption AND uses partial reads. That combination is rare outside kernel TLS-offload workloads. In practice this is a real bug worth patching, but not a fleet-wide fire — MEDIUM better reflects the operational risk on a general-purpose enterprise fleet.

Why this verdict

• Local-only vector: attacker must already own a shell on the box; the vuln is not a pivot into the host, it's a privilege step *after* initial access — worth a full CVSS point off the enterprise-realistic score.
• Trigger surface is attacker-controlled, not victim-controlled: unlike a network daemon UAF, no benign traffic triggers this. The attacker opens their own kTLS socket. Nothing about defending inbound traffic changes exposure — so perimeter and detection controls that usually mitigate kernel bugs (WAF, IDS) don't apply either way, but neither does organic exposure.
• No public exploit, no KEV, EPSS 0.0025: a kernel UAF in a niche subsystem that has sat for 16+ months without a weaponized PoC surfacing signals genuine exploitation difficulty; SLUB hardening on modern distro kernels breaks naive sprays.
• Role multiplier — general server / workstation: chain ends in local root on that one host. Blast radius = single host compromise from an already-compromised local account. Not fleet-scale.
• Role multiplier — TLS-terminating edge (HAProxy/nginx with kTLS, CDN nodes): these are exactly the hosts running kTLS RX in production. A compromised low-priv service account on such a node could plausibly reach root and pivot into cert material / session keys. This is the tail that keeps the verdict from dropping to LOW. Population <5% of enterprise Linux fleets — insufficient to floor at HIGH.
• Not a canonical high-value-role component: kTLS is a kernel feature, not a role — the affected code is not IN a hypervisor / IdP / PAM / backup / kernel-mode EDR. Floor rule does not force CRITICAL.

Why not higher?

HIGH would require either a remote vector, an active PoC, KEV listing, or evidence that a canonical high-value role (DC, IdP, PAM, hypervisor) universally runs kTLS RX. None of those apply. On TLS-terminating edge nodes the case for HIGH exists but the installed-base share (<5% of Linux fleet) is below the floor threshold.

Why not lower?

LOW would ignore that this is a genuine kernel UAF with a public root-cause commit — a competent attacker with msg_msg/pipe_buffer spray primitives and time on target can plausibly weaponize it, and any host that ever runs kTLS RX (nginx ssl_conf_command Options KTLS, HAProxy ssl-default-bind-options, Envoy) carries real LPE risk. The bug should still be patched on the normal kernel cadence, not deferred as backlog.

1. Prioritize kernel patch on TLS-terminating hosts — nginx, HAProxy, Envoy, and CDN edge nodes with kTLS enabled are the realistic exploitation surface. Patch these to the fixed kernel first (RHEL 9 5.14.0-427.13.1+, Ubuntu USN-6739-1+, SUSE SUSE-SU-2024:1149-1+). Deploy within 30 days per noisgate MEDIUM cadence; if you consider this tier HIGH internally, tighten to 30 days.
2. Disable kTLS RX where you don't need it — If you're not using kernel TLS offload for throughput, rmmod tls and blacklist the module via /etc/modprobe.d/blacklist-tls.conf (install tls /bin/true). Removes the vulnerable code path entirely on general-purpose servers.
3. Block TCP_ULP for unprivileged users via LSM — SELinux/AppArmor policy denying setsockopt with TCP_ULP for non-service domains eliminates the setup step for the attacker. On containers, drop CAP_NET_ADMIN and add seccomp filter denying setsockopt on SOL_TCP level=31 (TCP_ULP).
4. Tighten local-shell hygiene on kTLS hosts — Because the vector is PR:L, the mitigation compounds with any control that keeps arbitrary local users off TLS-terminating nodes: dedicated service accounts, no interactive login, PAM nologin, EDR alerts on shell spawn from nginx/haproxy UID.

Run on each target Linux host as root (or via your config-mgmt agent). Invoke as sudo ./check-cve-2024-26582.sh. Compares the running kernel version against the per-distro fixed builds and reports whether kTLS RX is even loadable. Exit code 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

#!/usr/bin/env bash
# noisgate: CVE-2024-26582 kTLS async-decrypt UAF check
# Requires: root recommended (for modinfo); works read-only otherwise.
set -u

KREL="$(uname -r)"
KVER="${KREL%%-*}"
ID="unknown"; VERSION_ID=""
[ -r /etc/os-release ] && . /etc/os-release

vercmp() { # returns 0 if $1 >= $2
  [ "$1" = "$2" ] && return 0
  printf '%s\n%s\n' "$2" "$1" | sort -V -C
}

# 1) Is CONFIG_TLS present in this kernel at all?
HAS_KTLS="unknown"
if [ -r "/boot/config-${KREL}" ]; then
  grep -q '^CONFIG_TLS=[ym]' "/boot/config-${KREL}" && HAS_KTLS=yes || HAS_KTLS=no
elif [ -r /proc/config.gz ]; then
  zgrep -q '^CONFIG_TLS=[ym]' /proc/config.gz && HAS_KTLS=yes || HAS_KTLS=no
fi

# 2) Distro fixed-version table
STATUS="UNKNOWN"
case "$ID" in
  rhel|centos|rocky|almalinux)
    # RHEL9 fix: kernel-5.14.0-427.13.1
    FIXED="5.14.0-427.13.1"
    if vercmp "$KREL" "$FIXED"; then STATUS=PATCHED; else STATUS=VULNERABLE; fi
    ;;
  ubuntu)
    # 22.04 GA: 5.15.0-102; 23.10: 6.5.0-27 (approx USN-6739/6740-1)
    case "$VERSION_ID" in
      22.04) FIXED="5.15.0-102";;
      23.10) FIXED="6.5.0-27";;
      24.04) FIXED="6.8.0-31";;
      *)     FIXED="";;
    esac
    if [ -n "$FIXED" ]; then
      RUNNING="$(echo "$KREL" | awk -F- '{print $1"-"$2}')"
      if vercmp "$RUNNING" "$FIXED"; then STATUS=PATCHED; else STATUS=VULNERABLE; fi
    fi
    ;;
  debian)
    # DSA-5658-1 shipped 6.1.85-1 on bookworm
    FIXED="6.1.85"
    if vercmp "$KVER" "$FIXED"; then STATUS=PATCHED; else STATUS=VULNERABLE; fi
    ;;
  sles|opensuse*|suse)
    # SUSE-SU-2024:1149-1 series
    FIXED_MAINLINE="6.4.0"
    if vercmp "$KVER" "$FIXED_MAINLINE"; then STATUS=PATCHED; else STATUS=VULNERABLE; fi
    ;;
  *)
    # Fall back to mainline stable cutoffs
    case "$KVER" in
      6.7.*)  vercmp "$KVER" "6.7.6"  && STATUS=PATCHED || STATUS=VULNERABLE ;;
      6.6.*)  vercmp "$KVER" "6.6.18" && STATUS=PATCHED || STATUS=VULNERABLE ;;
      6.1.*)  vercmp "$KVER" "6.1.79" && STATUS=PATCHED || STATUS=VULNERABLE ;;
      5.15.*|5.10.*|5.4.*) STATUS=UNKNOWN ;;
      *)      STATUS=UNKNOWN ;;
    esac
    ;;
esac

echo "kernel=${KREL} distro=${ID}-${VERSION_ID} ktls_config=${HAS_KTLS} status=${STATUS}"
case "$STATUS" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. NVD — CVE-2024-26582
2. Upstream fix commit (kernel.org)
3. Red Hat Bugzilla / CVE tracker
4. Ubuntu USN-6739-1
5. SUSE CVE page
6. Debian security tracker
7. kernel.org stable changelog 6.1.79
8. FIRST EPSS lookup