---
id: "CVE-2026-98725"
kind: "vulnerability"
aliases: ["CVE-2026-98725"]
title: "Linux kernel NVMe target: out-of-bounds write in NVMe-oF authentication challenge"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["linux-kernel", "nvme-target", "nvmet-tcp", "runtime", "self-hosted", "storage"]
not_affected_if: ["initiator-only", "no-nvme-target"]
published_at: "2026-10-18T16:17:26+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:17:20+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98725", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel NVMe target: out-of-bounds write in NVMe-oF authentication challenge

The Linux kernel's NVMe target authentication code computes the size of its challenge response using a void pointer, undercounting the fixed header by 15 bytes. A short AUTH_RECEIVE buffer can therefore pass the size check and let the kernel write past the end of a slab allocation.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the fixed kernel builds listed in the NVD record.
- Check whether the NVMe target is in use with `nvmetcli ls` or by looking for `/sys/kernel/config/nvmet`.
- Check whether NVMe-oF authentication (DH-HMAC-CHAP) is configured on any port or subsystem.

## Fix

- Update the Linux kernel to a stable release containing the upstream commit that uses the typed challenge pointer in nvmet_auth_challenge() (exact fixed versions: unknown, see NVD).
- Until patched, avoid exposing NVMe-oF target ports to untrusted networks.

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98725

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge()

nvmet_auth_challenge() receives its output buffer as a void pointer.
sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed
challenge header by 15 bytes.  A short AUTH_RECEIVE buffer can pass the
check before the challenge is copied past the end of its allocation.

Use the typed challenge pointer when calculating the response size.

  BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569)
  Write of size 32 by task kworker/1:1H/64
  Workqueue: nvmet_tcp_wq nvmet_tcp_io_work
  Call Trace:
  nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569)
  nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243)
  nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445)
  process_one_work (kernel/workqueue.c:3322)
  worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486)
  kthread (kernel/kthread.c:436)
  ret_from_fork (arch/x86/kernel/process.c:158)
  ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
  The buggy address is located 16 bytes inside of
   allocated 33-byte region [ffff888000554e80, ffff888000554ea1)
  Kernel panic - not syncing: KASAN: panic_on_warn set ...

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_