[PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Alison Schofield]

The CXL NVDIMM security passphrase key is looked up by the description
"nvdimm:" followed by the device serial string. For serial numbers of
10 and above, the kernel auto-unlock path fails to find the key
because ndctl names it with a decimal serial and the kernel uses hex.

That means a passphrase-protected device cannot be unlocked after a
reboot, and the pmem namespaces it backs do not come up. Devices
without an enrolled passphrase are unaffected.

The mismatch occurs for any serial number of 10 and above. Since CXL
device serial numbers are vendor-assigned 64-bit values, that covers
essentially all real hardware once security is enabled.

The 'id' sysfs attribute is established ABI that ndctl consumes as
decimal, so format the kernel's serial string the same way. A u64
decimal string requires up to 20 digits plus a NUL byte, so grow
CXL_DEV_ID_LEN to fit it.

The issue was exposed by CXL unit test cxl-security.sh when cxl_test
mock serial numbers were recently extended to 10 and above.

Cc: <stable@vger.kernel.org>
Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 drivers/cxl/core/pmem.c | 10 ++++++----
 drivers/cxl/cxl.h       |  3 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
index 68462e38a977..2ccdf04c1f43 100644
--- a/drivers/cxl/core/pmem.c
+++ b/drivers/cxl/core/pmem.c
@@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
 	dev->bus = &cxl_bus_type;
 	dev->type = &cxl_nvdimm_type;
 	/*
-	 * A "%llx" string is 17-bytes vs dimm_id that is max
-	 * NVDIMM_KEY_DESC_LEN
+	 * dev_id becomes the nvdimm dimm_id used for security key
+	 * lookups. Match the decimal serial emitted by the CXL 'id'
+	 * sysfs attribute. A u64 decimal string requires 20 digits
+	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
 	 */
-	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
+	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
 		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
-	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
+	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
 
 	return cxl_nvd;
 }
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 1297594beaec..3463faeb8a15 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -487,7 +487,8 @@ struct cxl_nvdimm_bridge {
 	struct nvdimm_bus_descriptor nd_desc;
 };
 
-#define CXL_DEV_ID_LEN 19
+/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
+#define CXL_DEV_ID_LEN 21
 
 enum {
 	CXL_NVD_F_INVALIDATED = 0,

base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
-- 
2.37.3

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Dave Jiang]

On 6/18/26 10:59 PM, Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
> 
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
> 
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
> 
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
> 
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently extended to 10 and above.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> ---
>  drivers/cxl/core/pmem.c | 10 ++++++----
>  drivers/cxl/cxl.h       |  3 ++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> index 68462e38a977..2ccdf04c1f43 100644
> --- a/drivers/cxl/core/pmem.c
> +++ b/drivers/cxl/core/pmem.c
> @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
>  	dev->bus = &cxl_bus_type;
>  	dev->type = &cxl_nvdimm_type;
>  	/*
> -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> -	 * NVDIMM_KEY_DESC_LEN
> +	 * dev_id becomes the nvdimm dimm_id used for security key
> +	 * lookups. Match the decimal serial emitted by the CXL 'id'
> +	 * sysfs attribute. A u64 decimal string requires 20 digits
> +	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
>  	 */
> -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||

Can CXL_DEV_ID_LEN be used here?

>  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> +	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
>  
>  	return cxl_nvd;
>  }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 1297594beaec..3463faeb8a15 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -487,7 +487,8 @@ struct cxl_nvdimm_bridge {
>  	struct nvdimm_bus_descriptor nd_desc;
>  };
>  
> -#define CXL_DEV_ID_LEN 19
> +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
> +#define CXL_DEV_ID_LEN 21
>  
>  enum {
>  	CXL_NVD_F_INVALIDATED = 0,
> 
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Alison Schofield]

On Mon, Jun 22, 2026 at 09:19:11AM -0700, Dave Jiang wrote:
> 
> 
> On 6/18/26 10:59 PM, Alison Schofield wrote:
> > The CXL NVDIMM security passphrase key is looked up by the description
> > "nvdimm:" followed by the device serial string. For serial numbers of
> > 10 and above, the kernel auto-unlock path fails to find the key
> > because ndctl names it with a decimal serial and the kernel uses hex.
> > 
> > That means a passphrase-protected device cannot be unlocked after a
> > reboot, and the pmem namespaces it backs do not come up. Devices
> > without an enrolled passphrase are unaffected.
> > 
> > The mismatch occurs for any serial number of 10 and above. Since CXL
> > device serial numbers are vendor-assigned 64-bit values, that covers
> > essentially all real hardware once security is enabled.
> > 
> > The 'id' sysfs attribute is established ABI that ndctl consumes as
> > decimal, so format the kernel's serial string the same way. A u64
> > decimal string requires up to 20 digits plus a NUL byte, so grow
> > CXL_DEV_ID_LEN to fit it.
> > 
> > The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> > mock serial numbers were recently extended to 10 and above.
> > 
> > Cc: <stable@vger.kernel.org>
> > Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> > ---
> >  drivers/cxl/core/pmem.c | 10 ++++++----
> >  drivers/cxl/cxl.h       |  3 ++-
> >  2 files changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> > index 68462e38a977..2ccdf04c1f43 100644
> > --- a/drivers/cxl/core/pmem.c
> > +++ b/drivers/cxl/core/pmem.c
> > @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
> >  	dev->bus = &cxl_bus_type;
> >  	dev->type = &cxl_nvdimm_type;
> >  	/*
> > -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> > -	 * NVDIMM_KEY_DESC_LEN
> > +	 * dev_id becomes the nvdimm dimm_id used for security key
> > +	 * lookups. Match the decimal serial emitted by the CXL 'id'
> > +	 * sysfs attribute. A u64 decimal string requires 20 digits
> > +	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
> >  	 */
> > -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> > +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
> 
> Can CXL_DEV_ID_LEN be used here?
> 

No. dev_id is defined as u8[CXL_DEV_ID_LEN], so sizeof(cxl_nvd->dev_id)
is already CXL_DEV_ID_LEN so that would make the check
CXL_DEV_ID_LEN < CXL_DEV_ID_LEN, and that is always false, never fires.

The 21 is the requirement (20 digits + NUL); sizeof() is what the buffer
provides. The check has to stay independent of the macro to have meaning.


> >  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> > -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> > +	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
> >  
> >  	return cxl_nvd;
> >  }

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Anisa Su]

On Thu, Jun 18, 2026 at 10:59:29PM -0700, Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
> 
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
> 
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
> 
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
> 
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently extended to 10 and above.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>

Thanks for the fix! Can confirm from my ndctl-test runner runs
that cxl-security.sh passes when applied on top of DCD v11 patches

https://github.com/anisa-su993/ndctl-test-runner/actions/workflows/main.yml

> ---
>  drivers/cxl/core/pmem.c | 10 ++++++----
>  drivers/cxl/cxl.h       |  3 ++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> index 68462e38a977..2ccdf04c1f43 100644
> --- a/drivers/cxl/core/pmem.c
> +++ b/drivers/cxl/core/pmem.c
> @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
>  	dev->bus = &cxl_bus_type;
>  	dev->type = &cxl_nvdimm_type;
>  	/*
> -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> -	 * NVDIMM_KEY_DESC_LEN
> +	 * dev_id becomes the nvdimm dimm_id used for security key
> +	 * lookups. Match the decimal serial emitted by the CXL 'id'
> +	 * sysfs attribute. A u64 decimal string requires 20 digits
> +	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
>  	 */
> -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
>  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> +	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
>  
>  	return cxl_nvd;
>  }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 1297594beaec..3463faeb8a15 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -487,7 +487,8 @@ struct cxl_nvdimm_bridge {
>  	struct nvdimm_bus_descriptor nd_desc;
>  };
>  
> -#define CXL_DEV_ID_LEN 19
> +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
> +#define CXL_DEV_ID_LEN 21
>  
>  enum {
>  	CXL_NVD_F_INVALIDATED = 0,
> 
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> -- 
> 2.37.3
> 

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Dan Williams (nvidia)]

Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
> 
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
> 
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
> 
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
> 
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently extended to 10 and above.

Good find!

This is a good fix for folks with new kernels and old tooling, but
leaves folks with old kernels in the lurch.

Not sure of the priority of doing this additional work given it is not
clear the CXL PMEM devices with security commands ever shipped, but
userspace tooling can workaround this problem by always injecting both
an nvdimm:%llx and nvdimm:%lld formatted key descriptor.

For the kernel change:

Acked-by: Dan Williams <djbw@kernel.org>

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Alison Schofield]

On Thu, Jun 25, 2026 at 12:38:55PM -0700, Dan Williams (nvidia) wrote:
> Alison Schofield wrote:
> > The CXL NVDIMM security passphrase key is looked up by the description
> > "nvdimm:" followed by the device serial string. For serial numbers of
> > 10 and above, the kernel auto-unlock path fails to find the key
> > because ndctl names it with a decimal serial and the kernel uses hex.
> > 
> > That means a passphrase-protected device cannot be unlocked after a
> > reboot, and the pmem namespaces it backs do not come up. Devices
> > without an enrolled passphrase are unaffected.
> > 
> > The mismatch occurs for any serial number of 10 and above. Since CXL
> > device serial numbers are vendor-assigned 64-bit values, that covers
> > essentially all real hardware once security is enabled.
> > 
> > The 'id' sysfs attribute is established ABI that ndctl consumes as
> > decimal, so format the kernel's serial string the same way. A u64
> > decimal string requires up to 20 digits plus a NUL byte, so grow
> > CXL_DEV_ID_LEN to fit it.
> > 
> > The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> > mock serial numbers were recently extended to 10 and above.
> 
> Good find!
> 
> This is a good fix for folks with new kernels and old tooling, but
> leaves folks with old kernels in the lurch.
> 
> Not sure of the priority of doing this additional work given it is not
> clear the CXL PMEM devices with security commands ever shipped, but
> userspace tooling can workaround this problem by always injecting both
> an nvdimm:%llx and nvdimm:%lld formatted key descriptor.

Hi Dan,

I tried this out, having load-keys install the same blob under both
dec and hex key descriptions. It can work, but a couple of potential
issues stopped me from moving ahead w it -

Shared keyring: these keys live on the per-uid user keyring (@u), not a
private ndctl keyring. Duplicating every key by default consumes space
in a shared system resource for what should only be a transitional
compatibility workaround. In practice the 1 MB quota is rarely a problem
because load-keys runs as root, but it is still unnecessary growth of a
shared keyring.

Clutter: an administrator running 'keyctl show' would see an extra
nvdimm:<hex> key that appears to belong to another dimm, and the key
description cannot be annotated because it must exactly match what the
kernel looks up.

I also considered an opt-in flag, like "ndctl load-keys --hex-compat".
But that mainly benefits users running old kernels with newer ndctl.
The primary audience, users staying on older kernels, seem unlikely to
update their ndctl tooling.

That left me back at a fix for stable PLUS a documented manual recovery
process. Appended below but not yet published.

And one more thing...while trying out all that I found a signedness issue
w the serial number representation. So I'm posting a new little series that
address that too and obsoletes this patch.

-- Alison


Manual recovery (for the documentation)
---------------------------------------

If a passphrase-protected CXL nvdimm does not auto-unlock after a reboot
-- it stays "locked" and the pmem namespaces it backs do not come up --
use the following to recover on a kernel that lacks the serial fix.

1. Confirm the device is actually locked, and that auto-unlock is what
   failed (not, say, a missing key blob or a hardware/security state
   issue):

     ndctl list -i -d nmemX | jq -r '.[].dimms[0].security'

   This should report "locked". If it reports "disabled" the device has
   no passphrase enrolled and this is a different problem; if it reports
   "unlocked" there is nothing to recover.

2. Confirm the failure is the serial-number format mismatch. The kernel
   looks the key up by a hex-formatted serial, while ndctl saved and
   named it by the decimal serial. They differ for any serial of 10 or
   greater. Compare the two spellings of this device's serial:

     # decimal serial, as ndctl named the key:
     cat /sys/bus/nd/devices/nmemX/cxl/id

     # hex serial, as the kernel looks it up:
     cat /sys/bus/cxl/devices/memY/serial

   If the decimal 'id' is 10 or greater (the hex and decimal forms are
   not the same string), you are hitting this issue. Confirm the key
   blob ndctl saved exists, named by the decimal serial:

     id=$(cat /sys/bus/nd/devices/nmemX/cxl/id)
     ls /etc/ndctl/keys/nvdimm_${id}_$(hostname).blob

   If that blob is missing, the key was never saved and this recovery
   does not apply -- re-enroll the passphrase instead.

3. Stage the same key blob under the hex-formatted serial so that
   load-keys also installs the key the kernel asks for:

     id=$(cat /sys/bus/nd/devices/nmemX/cxl/id)
     hexid=$(printf '%x' "$id")
     host=$(hostname)
     cp /etc/ndctl/keys/nvdimm_${id}_${host}.blob \
        /etc/ndctl/keys/nvdimm_${hexid}_${host}.blob

4. Reload the keys and bring the device up. load-keys derives the key
   description from the blob file name, so the copy is installed as the
   nvdimm:<hex> key the kernel requests:

     ndctl load-keys
     ndctl enable-dimm nmemX

   The device should now report "unlocked":

     ndctl list -i -d nmemX | jq -r '.[].dimms[0].security'

END manual recovery steps



> 
> For the kernel change:
> 
> Acked-by: Dan Williams <djbw@kernel.org>

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Dave Jiang]

On 6/18/26 10:59 PM, Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
> 
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
> 
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
> 
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
> 
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently extended to 10 and above.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>

Applied to cxl/next
2a77c0818e05

> ---
>  drivers/cxl/core/pmem.c | 10 ++++++----
>  drivers/cxl/cxl.h       |  3 ++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> index 68462e38a977..2ccdf04c1f43 100644
> --- a/drivers/cxl/core/pmem.c
> +++ b/drivers/cxl/core/pmem.c
> @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
>  	dev->bus = &cxl_bus_type;
>  	dev->type = &cxl_nvdimm_type;
>  	/*
> -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> -	 * NVDIMM_KEY_DESC_LEN
> +	 * dev_id becomes the nvdimm dimm_id used for security key
> +	 * lookups. Match the decimal serial emitted by the CXL 'id'
> +	 * sysfs attribute. A u64 decimal string requires 20 digits
> +	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
>  	 */
> -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
>  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> +	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
>  
>  	return cxl_nvd;
>  }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 1297594beaec..3463faeb8a15 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -487,7 +487,8 @@ struct cxl_nvdimm_bridge {
>  	struct nvdimm_bus_descriptor nd_desc;
>  };
>  
> -#define CXL_DEV_ID_LEN 19
> +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
> +#define CXL_DEV_ID_LEN 21
>  
>  enum {
>  	CXL_NVD_F_INVALIDATED = 0,
> 
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6

Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal

[Dave Jiang]

On 7/24/26 12:12 PM, Dave Jiang wrote:
> 
> 
> On 6/18/26 10:59 PM, Alison Schofield wrote:
>> The CXL NVDIMM security passphrase key is looked up by the description
>> "nvdimm:" followed by the device serial string. For serial numbers of
>> 10 and above, the kernel auto-unlock path fails to find the key
>> because ndctl names it with a decimal serial and the kernel uses hex.
>>
>> That means a passphrase-protected device cannot be unlocked after a
>> reboot, and the pmem namespaces it backs do not come up. Devices
>> without an enrolled passphrase are unaffected.
>>
>> The mismatch occurs for any serial number of 10 and above. Since CXL
>> device serial numbers are vendor-assigned 64-bit values, that covers
>> essentially all real hardware once security is enabled.
>>
>> The 'id' sysfs attribute is established ABI that ndctl consumes as
>> decimal, so format the kernel's serial string the same way. A u64
>> decimal string requires up to 20 digits plus a NUL byte, so grow
>> CXL_DEV_ID_LEN to fit it.
>>
>> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
>> mock serial numbers were recently extended to 10 and above.
>>
>> Cc: <stable@vger.kernel.org>
>> Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
>> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> 
> Applied to cxl/next
> 2a77c0818e05
> 

Backed out per request from Alison. There will be a v3. >> ---
>>  drivers/cxl/core/pmem.c | 10 ++++++----
>>  drivers/cxl/cxl.h       |  3 ++-
>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
>> index 68462e38a977..2ccdf04c1f43 100644
>> --- a/drivers/cxl/core/pmem.c
>> +++ b/drivers/cxl/core/pmem.c
>> @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
>>  	dev->bus = &cxl_bus_type;
>>  	dev->type = &cxl_nvdimm_type;
>>  	/*
>> -	 * A "%llx" string is 17-bytes vs dimm_id that is max
>> -	 * NVDIMM_KEY_DESC_LEN
>> +	 * dev_id becomes the nvdimm dimm_id used for security key
>> +	 * lookups. Match the decimal serial emitted by the CXL 'id'
>> +	 * sysfs attribute. A u64 decimal string requires 20 digits
>> +	 * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
>>  	 */
>> -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
>> +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
>>  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
>> -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
>> +	sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
>>  
>>  	return cxl_nvd;
>>  }
>> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
>> index 1297594beaec..3463faeb8a15 100644
>> --- a/drivers/cxl/cxl.h
>> +++ b/drivers/cxl/cxl.h
>> @@ -487,7 +487,8 @@ struct cxl_nvdimm_bridge {
>>  	struct nvdimm_bus_descriptor nd_desc;
>>  };
>>  
>> -#define CXL_DEV_ID_LEN 19
>> +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
>> +#define CXL_DEV_ID_LEN 21
>>  
>>  enum {
>>  	CXL_NVD_F_INVALIDATED = 0,
>>
>> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> 
>