In the Linux kernel

CVE-2026-53325 is a missing error-propagation fix in drivers/char/agp/amd64-agp.c, specifically in agp_amd64_probe(). When the probe path encountered a failure condition, it returned success instead of the underlying error, leaving downstream code to dereference a NULL pointer during AGP bridge initialization. Affected versions are mainline Linux kernels prior to the commit landing in 6.x stable; the bug touches only the AMD64 AGP (Accelerated Graphics Port) bridge driver, which exists almost exclusively on pre-2010 Athlon64/Opteron motherboards.

There is no vendor CVSS score and there shouldn't be a high one. The bug is reachable only at boot or module-load time on hardware that ships an AMD64 AGP north-bridge. There is no remote vector, no privilege boundary, and no path that an unprivileged user can take to trigger this — agp_amd64_probe() runs as part of kernel device enumeration. Calling this anything above LOW would be inflation.

Why this verdict

• No security boundary crossed: the bug is reachable only from agp_amd64_probe(), which runs in kernel context during device enumeration — there is no unprivileged or remote primitive.
• Affected hardware is functionally extinct in enterprise fleets: AMD64 AGP bridges are pre-PCIe-era; virtualized infrastructure does not expose this driver at all.
• Role multiplier: even on a hypothetical high-value role (DC, hypervisor, PAM appliance) the affected driver does not load — these run on modern PCIe-only hardware or VMs. There is no plausible high-value-role outcome, so the role-multiplier floor does not engage.
• Impact ceiling is a kernel oops triggered by root — a denial-of-self with no confidentiality or integrity impact, no memory disclosure described in the patch.

Why not higher?

MEDIUM would require either an unprivileged trigger path or meaningful integrity/confidentiality impact; neither exists. HIGH/CRITICAL would require remote reachability or a privilege-escalation primitive, and the patch description shows neither — it is an error-return cleanup, not a use-after-free or out-of-bounds write.

Why not lower?

IGNORE is tempting given the hardware is extinct, but distros will still ship the fix to long-term-support kernels and some embedded/industrial systems do still run AGP-era silicon. Calling it LOW keeps it on the routine kernel-update conveyor belt rather than letting auditors flag it as undocumented-risk-accepted.

1. Let it ride the next routine kernel update — Pick this up in your normal monthly/quarterly kernel rollup — no mitigation SLA applies at LOW. Treat as standard backlog hygiene under the noisgate 365-day remediation window.
2. Blacklist amd64-agp on modern fleets — Add blacklist amd64-agp to /etc/modprobe.d/noisgate-legacy.conf on any host that has no business loading legacy AGP drivers (every cloud VM, every post-2010 server). Eliminates the attack surface entirely until the patched kernel ships.
3. Inventory for AMD64 AGP hardware — Run lspci | grep -i agp across the fleet. If the count is zero — which it will be for ~99.9% of enterprise estates — you can document this CVE as not-applicable and move on.

Run on each Linux host as a non-root user (root not required for the checks). Invoke as bash check-cve-2026-53325.sh. The script reports VULNERABLE, PATCHED, or UNKNOWN and also surfaces whether the AGP hardware actually exists on the box — because if it doesn't, the bug is unreachable in practice.

#!/usr/bin/env bash
# noisgate verification: CVE-2026-53325 (agp/amd64 probe error-propagation)
# Exit codes: 0 = PATCHED or NOT_APPLICABLE, 1 = VULNERABLE, 2 = UNKNOWN
set -u

KVER="$(uname -r)"
echo "[*] Kernel: ${KVER}"

# 1. Is the AGP AMD64 hardware even present?
if command -v lspci >/dev/null 2>&1; then
  AGP_HW="$(lspci 2>/dev/null | grep -iE 'agp|amd64.*bridge' || true)"
else
  AGP_HW=""
fi

if [ -z "${AGP_HW}" ]; then
  echo "[+] No AMD64 AGP bridge detected — bug is unreachable on this host."
  echo "RESULT: NOT_APPLICABLE"
  exit 0
fi

echo "[!] AGP-class hardware detected:"
echo "${AGP_HW}"

# 2. Distro-specific patched-version lookup.
#    Replace the FIXED_* values once your distro publishes the backport metadata.
FIXED_RHEL="5.14.0-9999.el9"     # placeholder — update from RHSA
FIXED_UBUNTU="6.8.0-9999"         # placeholder — update from USN
FIXED_DEBIAN="6.1.0-9999"         # placeholder — update from DSA
FIXED_MAINLINE="6.10"             # placeholder — update from kernel.org

ID="$(. /etc/os-release 2>/dev/null && echo "${ID:-unknown}")"

compare_ge() {
  # returns 0 if $1 >= $2 using dpkg --compare-versions / rpmdev-vercmp fallback
  if command -v dpkg >/dev/null 2>&1; then
    dpkg --compare-versions "$1" ge "$2" && return 0 || return 1
  fi
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -1)" = "$2" ] && return 0 || return 1
}

case "${ID}" in
  rhel|centos|rocky|almalinux)
    TARGET="${FIXED_RHEL}" ;;
  ubuntu)
    TARGET="${FIXED_UBUNTU}" ;;
  debian)
    TARGET="${FIXED_DEBIAN}" ;;
  *)
    TARGET="${FIXED_MAINLINE}" ;;
esac

if compare_ge "${KVER}" "${TARGET}"; then
  echo "[+] Kernel ${KVER} >= fixed ${TARGET} for ${ID}"
  echo "RESULT: PATCHED"
  exit 0
fi

echo "[-] Kernel ${KVER} < fixed ${TARGET} for ${ID}"
echo "RESULT: VULNERABLE"
exit 1

Sources

1. Linux kernel CVE announce (linux-cve-announce list)
2. NVD entry CVE-2026-53325
3. kernel.org stable tree
4. drivers/char/agp/amd64-agp.c (upstream)
5. Ubuntu CVE tracker
6. Red Hat CVE database
7. Debian security tracker
8. FIRST EPSS