CVE-2026-89559

The Linux kernel's libnvdimm label-validation routine __nd_label_validate() bounds the on-media namespace index field nslot against the DIMM config area size, but because sizeof_namespace_label() returns unsigned, the product nslot * label_size is evaluated in 32-bit arithmetic and wraps, letting a crafted nslot pass the check. The value is then used as the loop trip count in nd_label_data_init(), whose memset() writes past the end of the config_size buffer, causing an out-of-bounds write in kernel memory. The malicious nslot can originate from tampered NVDIMM media or from local userspace via the ND_CMD_SET_CONFIG_DATA command, so a privileged local attacker (or one able to tamper with the medium) can achieve kernel memory corruption with high confidentiality, integrity, and availability impact (CVSS 3.1: 7.8). The check was originally safe when introduced by commit 4a826c83db4e (size_t multiplication) and regressed when commit 564e871aa66f made the label size a runtime value; only systems with NVDIMM/label-capable persistent memory hardware have the vulnerable path reachable. No public PoC exists and no exploitation in the wild is known.

What to do: Patch to a kernel release containing the fix (the product nslot * label_size is now evaluated in 64-bit) as soon as your distro ships it, prioritizing hosts that actually have NVDIMMs. Until then, restrict root access and access to /dev/nfit/* devices and the ndctl tooling on persistent-memory systems, since ND_CMD_SET_CONFIG_DATA is the userspace write path. Treat swapped-in or second-hand NVDIMM media as untrusted and re-validate labels after hardware changes.