CVE-2026-89965: nvdimm/btt: reject an arena whose nfree is below the lane count
In the Linux kernel, the following vulnerability has been resolved:
nvdimm/btt: reject an arena whose nfree is below the lane count
The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. bttfreelistinit() and bttrttinit() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from ndregionacquirelane(), which is bounded by ndregion->numlanes (NDMAXLANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write.
btt.rst documents the nlanes = min(nfree, numcpus) invariant, which the code does not currently honor: numlanes is NDMAXLANES regardless of nfree. Reject an arena whose nfree is below numlanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix to reject a BTT arena during discovery if the arena’s nfree (reserve free blocks) is below the lane count (nfree < num_lanes), before allocating per-lane arrays so the I/O path cannot index freelist[]/rtt[] past their allocation bounds.
Linux kernel nvdimm/btt arena.nfree validation at discovery (in btt_freelist_init/btt_rtt_init vs nd_region_acquire_lane) = reject arena when nfree < num_lanes (num_lanes = ND_MAX_LANES)
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems that discover and use an NVDIMM BTT arena are exposed when that arena has an nfree value lower than the region lane count. The affected component is the Linux kernel's nvdimm/btt implementation.
What must an attacker control to trigger the out-of-bounds write?
An attacker needs to provide or cause discovery of a crafted or foreign BTT arena whose on-media BTT info block reports nfree below num_lanes. The vulnerable I/O path can then index per-lane arrays using a lane value that exceeds their nfree-based allocation.
How can I tell whether an arena would be rejected by the fix?
Inspect the arena's BTT info block nfree value and compare it with the region's num_lanes value. An arena with nfree lower than num_lanes is the invalid condition addressed by the fix.
What is the practical mitigation if an update cannot be applied immediately?
Do not discover or use BTT arenas from untrusted, foreign, or otherwise unvalidated NVDIMM media. In particular, avoid arenas whose nfree value is below the region lane count.