On 2026-06-21, David Laight wrote:
> Is this enough and/or a sane way to stop the overflow.
For the overflow, yes. In 64-bit the product no longer wraps, so the bound
rejects exactly the nslot values that don't fit config_size. Minimal change,
backports cleanly.
> AFAICT label_size is either 128 or 258.
128 or 256. nd_label_validate() probes label_size[] = { 128, 256 } (v1.1 / v1.2)
and sets ndd->nslabel_size from that.
> But I can't see where nsarea.config_size is set.
A u32 filled by nvdimm_init_nsarea() from ND_CMD_GET_CONFIG_SIZE -- reported by
the dimm provider's ->ndctl (firmware/_DSM on NFIT), not a user ioctl. No sanity
cap today.
> The same could be done for nslot - any value above 64k is pretty much
> guaranteed to be garbage
Agreed. The largest legitimate nslot is config_size / label_size: a few hundred
on a real ~128K area, ~1024 at most. The exact bound already ties nslot to
config_size; a ceiling still helps for the gap you point at: config_size is
firmware-reported and uncapped, so a bogus large config_size would otherwise
admit a large nslot and kvzalloc.
I'd keep the (u64) cast as the targeted fix here (Fixes:/stable) and add the
nslot and config_size bounds as a follow-up hardening patch, or fold them into a
v2 if you'd rather see them together. Either way I'll send it.
Bryam
