ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
name into the caller buffer and then, for long snapshot names, appends
_<ino> with sprintf(p + elen, ...).

Some callers only provide NAME_MAX bytes. For long snapshot names, a
large inode suffix can push the final encoded name past NAME_MAX even
though the encrypted prefix stayed within the documented 240-byte
budget.

Format the suffix into a small local buffer first and reject names
whose suffix would exceed the caller's NAME_MAX output buffer.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- replace the raw suffix-size constants with a named maximum
- drop the impossible negative snprintf() check
- keep the NAME_MAX bound check local to the formatted suffix length

fs/ceph/crypto.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
index f3de43ccb470..7712557660c3 100644
--- a/fs/ceph/crypto.c
+++ b/fs/ceph/crypto.c
@@ -15,6 +15,8 @@
 #include "mds_client.h"
 #include "crypto.h"
 
+#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
+
 static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
 {
 	struct ceph_inode_info *ci = ceph_inode(inode);
@@ -271,8 +273,19 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 
 	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
 	WARN_ON(elen > 240);
-	if (dir != parent) // leading _ is already there; append _<inum>
-		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
+	if (dir != parent) {
+		/* leading '_' is already there; append _<inum> */
+		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
+
+		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
+		if (ret >= sizeof(suffix) || ret >= NAME_MAX - elen) {
+			elen = -ENAMETOOLONG;
+			goto out;
+		}
+
+		memcpy(p + elen, suffix, ret);
+		elen += ret + 1;
+	}
 
 out:
 	kfree(cryptbuf);
-- 
2.50.1 (Apple Git-155)

On Tue, 2026-04-07 at 09:57 +0800, Pengpeng Hou wrote:
> ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> name into the caller buffer and then, for long snapshot names, appends
> _<ino> with sprintf(p + elen, ...).
> 
> Some callers only provide NAME_MAX bytes. For long snapshot names, a
> large inode suffix can push the final encoded name past NAME_MAX even
> though the encrypted prefix stayed within the documented 240-byte
> budget.
> 
> Format the suffix into a small local buffer first and reject names
> whose suffix would exceed the caller's NAME_MAX output buffer.
> 
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since v1:
> - replace the raw suffix-size constants with a named maximum
> - drop the impossible negative snprintf() check
> - keep the NAME_MAX bound check local to the formatted suffix length
> 
> fs/ceph/crypto.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> index f3de43ccb470..7712557660c3 100644
> --- a/fs/ceph/crypto.c
> +++ b/fs/ceph/crypto.c
> @@ -15,6 +15,8 @@
>  #include "mds_client.h"
>  #include "crypto.h"
>  
> +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")

These define is much better. But I am still thinking could we have a more
elegant solution here? :) Do you have any ideas? Maybe, do we need to introduce
some macro DECIMAL_DIGITS_MAX()? At minimum, we need to have a comment here.

> +
>  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
>  {
>  	struct ceph_inode_info *ci = ceph_inode(inode);
> @@ -271,8 +273,19 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  
>  	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
>  	WARN_ON(elen > 240);
> -	if (dir != parent) // leading _ is already there; append _<inum>
> -		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> +	if (dir != parent) {
> +		/* leading '_' is already there; append _<inum> */
> +		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> +
> +		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> +		if (ret >= sizeof(suffix) || ret >= NAME_MAX - elen) {

It looks like that ret >= sizeof(suffix) is dead code. The sizeof(suffix) = 22.
The maximum possible suffix is _18446744073709551615 = 21 chars → snprintf
returns 21, never ≥ 22.

> +			elen = -ENAMETOOLONG;
> +			goto out;
> +		}
> +
> +		memcpy(p + elen, suffix, ret);
> +		elen += ret + 1;

I believe we need to have a comment here. The +1 is not for the NUL — it
accounts for the leading _ at buf[0]. Without a comment it could be confusing.

Thanks,
Slava.

> +	}
>  
>  out:
>  	kfree(cryptbuf);

ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
name into the caller buffer and then, for long snapshot names, appends
_<ino> with sprintf(p + elen, ...).

Some callers only provide NAME_MAX bytes. For long snapshot names, a
large inode suffix can push the final encoded name past NAME_MAX even
though the encrypted prefix stayed within the documented 240-byte
budget.

Format the suffix into a small local buffer first and reject names
whose suffix would exceed the caller's NAME_MAX output buffer.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>

---
Changes since v2:
- document the suffix buffer size with a comment
- drop the dead ret >= sizeof(suffix) check
- track the skipped leading '_' explicitly via prefix_len
---
 fs/ceph/crypto.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
index f3de43ccb470..7989056a463c 100644
--- a/fs/ceph/crypto.c
+++ b/fs/ceph/crypto.c
@@ -15,6 +15,12 @@
 #include "mds_client.h"
 #include "crypto.h"
 
+/*
+ * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
+ * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
+ */
+#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
+
 static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
 {
 	struct ceph_inode_info *ci = ceph_inode(inode);
@@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 	struct inode *dir = parent;
 	char *p = buf;
 	u32 len;
+	int prefix_len = 0;
 	int name_len = elen;
 	int ret;
 	u8 *cryptbuf = NULL;
@@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 		if (IS_ERR(dir))
 			return PTR_ERR(dir);
 		p++; /* skip initial '_' */
+		prefix_len = 1;
 	}
 
 	if (!fscrypt_has_encryption_key(dir))
@@ -271,8 +279,20 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 
 	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
 	WARN_ON(elen > 240);
-	if (dir != parent) // leading _ is already there; append _<inum>
-		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
+	if (dir != parent) {
+		/* leading '_' is already there; append _<inum> */
+		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
+
+		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
+		if (ret > NAME_MAX - prefix_len - elen) {
+			elen = -ENAMETOOLONG;
+			goto out;
+		}
+
+		memcpy(p + elen, suffix, ret);
+		/* Include the leading '_' skipped by p. */
+		elen += ret + prefix_len;
+	}
 
 out:
 	kfree(cryptbuf);
-- 
2.50.1 (Apple Git-155)

On Wed, 2026-04-08 at 08:57 +0800, Pengpeng Hou wrote:
> ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> name into the caller buffer and then, for long snapshot names, appends
> _<ino> with sprintf(p + elen, ...).
> 
> Some callers only provide NAME_MAX bytes. For long snapshot names, a
> large inode suffix can push the final encoded name past NAME_MAX even
> though the encrypted prefix stayed within the documented 240-byte
> budget.
> 
> Format the suffix into a small local buffer first and reject names
> whose suffix would exceed the caller's NAME_MAX output buffer.
> 
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> 
> ---
> Changes since v2:
> - document the suffix buffer size with a comment
> - drop the dead ret >= sizeof(suffix) check
> - track the skipped leading '_' explicitly via prefix_len
> ---
>  fs/ceph/crypto.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> index f3de43ccb470..7989056a463c 100644
> --- a/fs/ceph/crypto.c
> +++ b/fs/ceph/crypto.c
> @@ -15,6 +15,12 @@
>  #include "mds_client.h"
>  #include "crypto.h"
>  
> +/*
> + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
> + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
> + */
> +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
> +
>  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
>  {
>  	struct ceph_inode_info *ci = ceph_inode(inode);
> @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  	struct inode *dir = parent;
>  	char *p = buf;
>  	u32 len;
> +	int prefix_len = 0;
>  	int name_len = elen;
>  	int ret;
>  	u8 *cryptbuf = NULL;
> @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  		if (IS_ERR(dir))
>  			return PTR_ERR(dir);
>  		p++; /* skip initial '_' */
> +		prefix_len = 1;
>  	}
>  
>  	if (!fscrypt_has_encryption_key(dir))
> @@ -271,8 +279,20 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  
>  	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
>  	WARN_ON(elen > 240);
> -	if (dir != parent) // leading _ is already there; append _<inum>
> -		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> +	if (dir != parent) {
> +		/* leading '_' is already there; append _<inum> */
> +		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> +
> +		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> +		if (ret > NAME_MAX - prefix_len - elen) {

The patch looks much cleaner now. But I am still slightly worried about this
calculation. Yes, we have WARN_ON(elen > 240) but it doesn't stop the execution
flow. And, finally, NAME_MAX - prefix_len - elen could have overflow and it
could behave incorrectly. Maybe, we need to add the check if (elen > 240) here?
What do you think?

Thanks,
Slava.

> +			elen = -ENAMETOOLONG;
> +			goto out;
> +		}
> +
> +		memcpy(p + elen, suffix, ret);
> +		/* Include the leading '_' skipped by p. */
> +		elen += ret + prefix_len;
> +	}
>  
>  out:
>  	kfree(cryptbuf);

ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
name into the caller buffer and then, for long snapshot names, appends
_<ino> with sprintf(p + elen, ...).

Some callers only provide NAME_MAX bytes. For long snapshot names, a
large inode suffix can push the final encoded name past NAME_MAX even
though the encrypted prefix stayed within the documented 240-byte
budget.

Format the suffix into a small local buffer first and reject names
whose suffix would exceed the caller's NAME_MAX output buffer.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v3:
- reject `elen > 240` explicitly instead of relying only on the earlier
  `WARN_ON()`
- rewrite the NAME_MAX bound check in terms of the final total length
  instead of `NAME_MAX - prefix_len - elen`

 fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
index f3de43ccb470..42e3fff34697 100644
--- a/fs/ceph/crypto.c
+++ b/fs/ceph/crypto.c
@@ -15,6 +15,12 @@
 #include "mds_client.h"
 #include "crypto.h"
 
+/*
+ * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
+ * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
+ */
+#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
+
 static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
 {
 	struct ceph_inode_info *ci = ceph_inode(inode);
@@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 	struct inode *dir = parent;
 	char *p = buf;
 	u32 len;
+	int prefix_len = 0;
 	int name_len = elen;
 	int ret;
 	u8 *cryptbuf = NULL;
@@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 		if (IS_ERR(dir))
 			return PTR_ERR(dir);
 		p++; /* skip initial '_' */
+		prefix_len = 1;
 	}
 
 	if (!fscrypt_has_encryption_key(dir))
@@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
 
 	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
 	WARN_ON(elen > 240);
-	if (dir != parent) // leading _ is already there; append _<inum>
-		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
+	if (elen > 240) {
+		elen = -ENAMETOOLONG;
+		goto out;
+	}
+
+	if (dir != parent) {
+		int total_len;
+		/* leading '_' is already there; append _<inum> */
+		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
+
+		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
+		total_len = prefix_len + elen + ret;
+		if (total_len > NAME_MAX) {
+			elen = -ENAMETOOLONG;
+			goto out;
+		}
+
+		memcpy(p + elen, suffix, ret);
+		/* Include the leading '_' skipped by p. */
+		elen = total_len;
+	}
 
 out:
 	kfree(cryptbuf);
-- 
2.50.1 (Apple Git-155)

On Thu, 2026-04-09 at 10:39 +0800, Pengpeng Hou wrote:
> ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> name into the caller buffer and then, for long snapshot names, appends
> _<ino> with sprintf(p + elen, ...).
> 
> Some callers only provide NAME_MAX bytes. For long snapshot names, a
> large inode suffix can push the final encoded name past NAME_MAX even
> though the encrypted prefix stayed within the documented 240-byte
> budget.
> 
> Format the suffix into a small local buffer first and reject names
> whose suffix would exceed the caller's NAME_MAX output buffer.
> 
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since v3:
> - reject `elen > 240` explicitly instead of relying only on the earlier
>   `WARN_ON()`
> - rewrite the NAME_MAX bound check in terms of the final total length
>   instead of `NAME_MAX - prefix_len - elen`
> 
>  fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> index f3de43ccb470..42e3fff34697 100644
> --- a/fs/ceph/crypto.c
> +++ b/fs/ceph/crypto.c
> @@ -15,6 +15,12 @@
>  #include "mds_client.h"
>  #include "crypto.h"
>  
> +/*
> + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
> + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
> + */
> +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
> +
>  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
>  {
>  	struct ceph_inode_info *ci = ceph_inode(inode);
> @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  	struct inode *dir = parent;
>  	char *p = buf;
>  	u32 len;
> +	int prefix_len = 0;
>  	int name_len = elen;
>  	int ret;
>  	u8 *cryptbuf = NULL;
> @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  		if (IS_ERR(dir))
>  			return PTR_ERR(dir);
>  		p++; /* skip initial '_' */
> +		prefix_len = 1;
>  	}
>  
>  	if (!fscrypt_has_encryption_key(dir))
> @@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>  
>  	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
>  	WARN_ON(elen > 240);
> -	if (dir != parent) // leading _ is already there; append _<inum>
> -		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> +	if (elen > 240) {
> +		elen = -ENAMETOOLONG;
> +		goto out;
> +	}
> +
> +	if (dir != parent) {
> +		int total_len;
> +		/* leading '_' is already there; append _<inum> */
> +		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> +
> +		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> +		total_len = prefix_len + elen + ret;
> +		if (total_len > NAME_MAX) {
> +			elen = -ENAMETOOLONG;
> +			goto out;
> +		}
> +
> +		memcpy(p + elen, suffix, ret);
> +		/* Include the leading '_' skipped by p. */
> +		elen = total_len;
> +	}
>  
>  out:
>  	kfree(cryptbuf);

Looks good.

Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Let me run xfstests for the patch to double check that everything is OK. I'll
share the result ASAP.

Thanks,
Slava.

On Thu, 2026-04-09 at 18:09 +0000, Viacheslav Dubeyko wrote:
> On Thu, 2026-04-09 at 10:39 +0800, Pengpeng Hou wrote:
> > ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> > name into the caller buffer and then, for long snapshot names, appends
> > _<ino> with sprintf(p + elen, ...).
> > 
> > Some callers only provide NAME_MAX bytes. For long snapshot names, a
> > large inode suffix can push the final encoded name past NAME_MAX even
> > though the encrypted prefix stayed within the documented 240-byte
> > budget.
> > 
> > Format the suffix into a small local buffer first and reject names
> > whose suffix would exceed the caller's NAME_MAX output buffer.
> > 
> > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> > ---
> > Changes since v3:
> > - reject `elen > 240` explicitly instead of relying only on the earlier
> >   `WARN_ON()`
> > - rewrite the NAME_MAX bound check in terms of the final total length
> >   instead of `NAME_MAX - prefix_len - elen`
> > 
> >  fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> > index f3de43ccb470..42e3fff34697 100644
> > --- a/fs/ceph/crypto.c
> > +++ b/fs/ceph/crypto.c
> > @@ -15,6 +15,12 @@
> >  #include "mds_client.h"
> >  #include "crypto.h"
> >  
> > +/*
> > + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
> > + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
> > + */
> > +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
> > +
> >  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
> >  {
> >  	struct ceph_inode_info *ci = ceph_inode(inode);
> > @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> >  	struct inode *dir = parent;
> >  	char *p = buf;
> >  	u32 len;
> > +	int prefix_len = 0;
> >  	int name_len = elen;
> >  	int ret;
> >  	u8 *cryptbuf = NULL;
> > @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> >  		if (IS_ERR(dir))
> >  			return PTR_ERR(dir);
> >  		p++; /* skip initial '_' */
> > +		prefix_len = 1;
> >  	}
> >  
> >  	if (!fscrypt_has_encryption_key(dir))
> > @@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> >  
> >  	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
> >  	WARN_ON(elen > 240);
> > -	if (dir != parent) // leading _ is already there; append _<inum>
> > -		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> > +	if (elen > 240) {
> > +		elen = -ENAMETOOLONG;
> > +		goto out;
> > +	}
> > +
> > +	if (dir != parent) {
> > +		int total_len;
> > +		/* leading '_' is already there; append _<inum> */
> > +		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> > +
> > +		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> > +		total_len = prefix_len + elen + ret;
> > +		if (total_len > NAME_MAX) {
> > +			elen = -ENAMETOOLONG;
> > +			goto out;
> > +		}
> > +
> > +		memcpy(p + elen, suffix, ret);
> > +		/* Include the leading '_' skipped by p. */
> > +		elen = total_len;
> > +	}
> >  
> >  out:
> >  	kfree(cryptbuf);
> 
> Looks good.
> 
> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> 
> Let me run xfstests for the patch to double check that everything is OK. I'll
> share the result ASAP.
> 

The xfstests run was successful. I don't see any issues with the patch.

Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Thanks,
Slava.

On Fri, 2026-04-10 at 20:40 +0000, Viacheslav Dubeyko wrote:
> On Thu, 2026-04-09 at 18:09 +0000, Viacheslav Dubeyko wrote:
> > On Thu, 2026-04-09 at 10:39 +0800, Pengpeng Hou wrote:
> > > ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> > > name into the caller buffer and then, for long snapshot names, appends
> > > _<ino> with sprintf(p + elen, ...).
> > > 
> > > Some callers only provide NAME_MAX bytes. For long snapshot names, a
> > > large inode suffix can push the final encoded name past NAME_MAX even
> > > though the encrypted prefix stayed within the documented 240-byte
> > > budget.
> > > 
> > > Format the suffix into a small local buffer first and reject names
> > > whose suffix would exceed the caller's NAME_MAX output buffer.
> > > 
> > > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> > > ---
> > > Changes since v3:
> > > - reject `elen > 240` explicitly instead of relying only on the earlier
> > >   `WARN_ON()`
> > > - rewrite the NAME_MAX bound check in terms of the final total length
> > >   instead of `NAME_MAX - prefix_len - elen`
> > > 
> > >  fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
> > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> > > index f3de43ccb470..42e3fff34697 100644
> > > --- a/fs/ceph/crypto.c
> > > +++ b/fs/ceph/crypto.c
> > > @@ -15,6 +15,12 @@
> > >  #include "mds_client.h"
> > >  #include "crypto.h"
> > >  
> > > +/*
> > > + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
> > > + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
> > > + */
> > > +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX	sizeof("_18446744073709551615")
> > > +
> > >  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
> > >  {
> > >  	struct ceph_inode_info *ci = ceph_inode(inode);
> > > @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > >  	struct inode *dir = parent;
> > >  	char *p = buf;
> > >  	u32 len;
> > > +	int prefix_len = 0;
> > >  	int name_len = elen;
> > >  	int ret;
> > >  	u8 *cryptbuf = NULL;
> > > @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > >  		if (IS_ERR(dir))
> > >  			return PTR_ERR(dir);
> > >  		p++; /* skip initial '_' */
> > > +		prefix_len = 1;
> > >  	}
> > >  
> > >  	if (!fscrypt_has_encryption_key(dir))
> > > @@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > >  
> > >  	/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
> > >  	WARN_ON(elen > 240);
> > > -	if (dir != parent) // leading _ is already there; append _<inum>
> > > -		elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> > > +	if (elen > 240) {
> > > +		elen = -ENAMETOOLONG;
> > > +		goto out;
> > > +	}
> > > +
> > > +	if (dir != parent) {
> > > +		int total_len;
> > > +		/* leading '_' is already there; append _<inum> */
> > > +		char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> > > +
> > > +		ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> > > +		total_len = prefix_len + elen + ret;
> > > +		if (total_len > NAME_MAX) {
> > > +			elen = -ENAMETOOLONG;
> > > +			goto out;
> > > +		}
> > > +
> > > +		memcpy(p + elen, suffix, ret);
> > > +		/* Include the leading '_' skipped by p. */
> > > +		elen = total_len;
> > > +	}
> > >  
> > >  out:
> > >  	kfree(cryptbuf);
> > 
> > Looks good.
> > 
> > Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > 
> > Let me run xfstests for the patch to double check that everything is OK. I'll
> > share the result ASAP.
> > 
> 
> The xfstests run was successful. I don't see any issues with the patch.
> 
> Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> 
> 

Applied on testing branch of CephFS kernel client git tree.

Thanks,
Slava.

On Fri, Apr 10, 2026 at 10:46 PM Viacheslav Dubeyko
<Slava.Dubeyko@ibm.com> wrote:
>
> On Fri, 2026-04-10 at 20:40 +0000, Viacheslav Dubeyko wrote:
> > On Thu, 2026-04-09 at 18:09 +0000, Viacheslav Dubeyko wrote:
> > > On Thu, 2026-04-09 at 10:39 +0800, Pengpeng Hou wrote:
> > > > ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
> > > > name into the caller buffer and then, for long snapshot names, appends
> > > > _<ino> with sprintf(p + elen, ...).
> > > >
> > > > Some callers only provide NAME_MAX bytes. For long snapshot names, a
> > > > large inode suffix can push the final encoded name past NAME_MAX even
> > > > though the encrypted prefix stayed within the documented 240-byte
> > > > budget.
> > > >
> > > > Format the suffix into a small local buffer first and reject names
> > > > whose suffix would exceed the caller's NAME_MAX output buffer.
> > > >
> > > > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> > > > ---
> > > > Changes since v3:
> > > > - reject `elen > 240` explicitly instead of relying only on the earlier
> > > >   `WARN_ON()`
> > > > - rewrite the NAME_MAX bound check in terms of the final total length
> > > >   instead of `NAME_MAX - prefix_len - elen`
> > > >
> > > >  fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
> > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
> > > > index f3de43ccb470..42e3fff34697 100644
> > > > --- a/fs/ceph/crypto.c
> > > > +++ b/fs/ceph/crypto.c
> > > > @@ -15,6 +15,12 @@
> > > >  #include "mds_client.h"
> > > >  #include "crypto.h"
> > > >
> > > > +/*
> > > > + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
> > > > + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
> > > > + */
> > > > +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX       sizeof("_18446744073709551615")
> > > > +
> > > >  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
> > > >  {
> > > >   struct ceph_inode_info *ci = ceph_inode(inode);
> > > > @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > > >   struct inode *dir = parent;
> > > >   char *p = buf;
> > > >   u32 len;
> > > > + int prefix_len = 0;
> > > >   int name_len = elen;
> > > >   int ret;
> > > >   u8 *cryptbuf = NULL;
> > > > @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > > >           if (IS_ERR(dir))
> > > >                   return PTR_ERR(dir);
> > > >           p++; /* skip initial '_' */
> > > > +         prefix_len = 1;
> > > >   }
> > > >
> > > >   if (!fscrypt_has_encryption_key(dir))
> > > > @@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
> > > >
> > > >   /* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
> > > >   WARN_ON(elen > 240);
> > > > - if (dir != parent) // leading _ is already there; append _<inum>
> > > > -         elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
> > > > + if (elen > 240) {
> > > > +         elen = -ENAMETOOLONG;
> > > > +         goto out;
> > > > + }
> > > > +
> > > > + if (dir != parent) {
> > > > +         int total_len;
> > > > +         /* leading '_' is already there; append _<inum> */
> > > > +         char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
> > > > +
> > > > +         ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
> > > > +         total_len = prefix_len + elen + ret;
> > > > +         if (total_len > NAME_MAX) {
> > > > +                 elen = -ENAMETOOLONG;
> > > > +                 goto out;
> > > > +         }
> > > > +
> > > > +         memcpy(p + elen, suffix, ret);
> > > > +         /* Include the leading '_' skipped by p. */
> > > > +         elen = total_len;
> > > > + }
> > > >
> > > >  out:
> > > >   kfree(cryptbuf);
> > >
> > > Looks good.
> > >
> > > Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > >
> > > Let me run xfstests for the patch to double check that everything is OK. I'll
> > > share the result ASAP.
> > >
> >
> > The xfstests run was successful. I don't see any issues with the patch.
> >
> > Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> >
> >
>
> Applied on testing branch of CephFS kernel client git tree.

Hi Pengpeng, Slava,

This patch raised my attention because my understanding was that the
entire CEPH_NOHASH_NAME_MAX + sha256() was put in place precisely to
handle longer names nicely and make them fit into NAME_MAX-sized buffer.
Simply rejecting longer names seemed to be in direct contradiction with
that and yet the patch on its own was clearly merited given

 * (240 bytes is the maximum size allowed for snapshot names to take into
 *  account the format: '_<SNAPSHOT-NAME>_<INODE-NUMBER>'.)

comment on CEPH_NOHASH_NAME_MAX definition.

I dug a bit deeper and started a discussion in [1].  The preliminary
conclusion is that the 240 bytes assumption was a mistake -- somehow
the minimum number of characters needed for <inum> ended up being used
instead of the maximum.  CEPH_NOHASH_NAME_MAX value is likely incorrect
and should have been smaller -- something along the lines of 174 -
SHA256_DIGEST_SIZE instead of 180 - SHA256_DIGEST_SIZE.

I kept this patch in the testing branch but not including it for 7.1
pending further investigation.

[1] https://github.com/ceph/ceph/pull/45312

Thanks,

                Ilya

On Wed, Apr 22 2026, Ilya Dryomov wrote:

> On Fri, Apr 10, 2026 at 10:46 PM Viacheslav Dubeyko
> <Slava.Dubeyko@ibm.com> wrote:
>>
>> On Fri, 2026-04-10 at 20:40 +0000, Viacheslav Dubeyko wrote:
>> > On Thu, 2026-04-09 at 18:09 +0000, Viacheslav Dubeyko wrote:
>> > > On Thu, 2026-04-09 at 10:39 +0800, Pengpeng Hou wrote:
>> > > > ceph_encode_encrypted_dname() base64-encodes the encrypted snapshot
>> > > > name into the caller buffer and then, for long snapshot names, appends
>> > > > _<ino> with sprintf(p + elen, ...).
>> > > >
>> > > > Some callers only provide NAME_MAX bytes. For long snapshot names, a
>> > > > large inode suffix can push the final encoded name past NAME_MAX even
>> > > > though the encrypted prefix stayed within the documented 240-byte
>> > > > budget.
>> > > >
>> > > > Format the suffix into a small local buffer first and reject names
>> > > > whose suffix would exceed the caller's NAME_MAX output buffer.
>> > > >
>> > > > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>> > > > ---
>> > > > Changes since v3:
>> > > > - reject `elen > 240` explicitly instead of relying only on the earlier
>> > > >   `WARN_ON()`
>> > > > - rewrite the NAME_MAX bound check in terms of the final total length
>> > > >   instead of `NAME_MAX - prefix_len - elen`
>> > > >
>> > > >  fs/ceph/crypto.c | 31 +++++++++++++++++++++++++++++--
>> > > >  1 file changed, 29 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
>> > > > index f3de43ccb470..42e3fff34697 100644
>> > > > --- a/fs/ceph/crypto.c
>> > > > +++ b/fs/ceph/crypto.c
>> > > > @@ -15,6 +15,12 @@
>> > > >  #include "mds_client.h"
>> > > >  #include "crypto.h"
>> > > >
>> > > > +/*
>> > > > + * Reserve room for '_' + decimal 64-bit inode number + trailing NUL.
>> > > > + * ceph_encode_encrypted_dname() copies only the visible suffix bytes.
>> > > > + */
>> > > > +#define CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX       sizeof("_18446744073709551615")
>> > > > +
>> > > >  static int ceph_crypt_get_context(struct inode *inode, void *ctx, size_t len)
>> > > >  {
>> > > >   struct ceph_inode_info *ci = ceph_inode(inode);
>> > > > @@ -209,6 +215,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>> > > >   struct inode *dir = parent;
>> > > >   char *p = buf;
>> > > >   u32 len;
>> > > > + int prefix_len = 0;
>> > > >   int name_len = elen;
>> > > >   int ret;
>> > > >   u8 *cryptbuf = NULL;
>> > > > @@ -219,6 +226,7 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>> > > >           if (IS_ERR(dir))
>> > > >                   return PTR_ERR(dir);
>> > > >           p++; /* skip initial '_' */
>> > > > +         prefix_len = 1;
>> > > >   }
>> > > >
>> > > >   if (!fscrypt_has_encryption_key(dir))
>> > > > @@ -271,8 +279,27 @@ int ceph_encode_encrypted_dname(struct inode *parent, char *buf, int elen)
>> > > >
>> > > >   /* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
>> > > >   WARN_ON(elen > 240);
>> > > > - if (dir != parent) // leading _ is already there; append _<inum>
>> > > > -         elen += 1 + sprintf(p + elen, "_%ld", dir->i_ino);
>> > > > + if (elen > 240) {
>> > > > +         elen = -ENAMETOOLONG;
>> > > > +         goto out;
>> > > > + }
>> > > > +
>> > > > + if (dir != parent) {
>> > > > +         int total_len;
>> > > > +         /* leading '_' is already there; append _<inum> */
>> > > > +         char suffix[CEPH_ENCRYPTED_SNAP_INO_SUFFIX_MAX];
>> > > > +
>> > > > +         ret = snprintf(suffix, sizeof(suffix), "_%lu", dir->i_ino);
>> > > > +         total_len = prefix_len + elen + ret;
>> > > > +         if (total_len > NAME_MAX) {
>> > > > +                 elen = -ENAMETOOLONG;
>> > > > +                 goto out;
>> > > > +         }
>> > > > +
>> > > > +         memcpy(p + elen, suffix, ret);
>> > > > +         /* Include the leading '_' skipped by p. */
>> > > > +         elen = total_len;
>> > > > + }
>> > > >
>> > > >  out:
>> > > >   kfree(cryptbuf);
>> > >
>> > > Looks good.
>> > >
>> > > Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>> > >
>> > > Let me run xfstests for the patch to double check that everything is OK. I'll
>> > > share the result ASAP.
>> > >
>> >
>> > The xfstests run was successful. I don't see any issues with the patch.
>> >
>> > Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>> >
>> >
>>
>> Applied on testing branch of CephFS kernel client git tree.
>
> Hi Pengpeng, Slava,
>
> This patch raised my attention because my understanding was that the
> entire CEPH_NOHASH_NAME_MAX + sha256() was put in place precisely to
> handle longer names nicely and make them fit into NAME_MAX-sized buffer.
> Simply rejecting longer names seemed to be in direct contradiction with
> that and yet the patch on its own was clearly merited given
>
>  * (240 bytes is the maximum size allowed for snapshot names to take into
>  *  account the format: '_<SNAPSHOT-NAME>_<INODE-NUMBER>'.)
>
> comment on CEPH_NOHASH_NAME_MAX definition.
>
> I dug a bit deeper and started a discussion in [1].  The preliminary
> conclusion is that the 240 bytes assumption was a mistake -- somehow
> the minimum number of characters needed for <inum> ended up being used
> instead of the maximum.  CEPH_NOHASH_NAME_MAX value is likely incorrect
> and should have been smaller -- something along the lines of 174 -
> SHA256_DIGEST_SIZE instead of 180 - SHA256_DIGEST_SIZE.

FWIW I _think_ Ilya may be correct, and there's actually an issue when
these constants were defined.  I spent quite some time last evening trying
to dig into the details on why the inode length was assumed to be 13.
Apparently, it was just a mistake that no one spotted at the time :-(

Unfortunately, my bandwidth to look into this is quite limited.  But I
believe it should be easy to verify that this is indeed a bug by simply
creating snapshots on an encrypted directory that has an inode number
bigger than 2^40 and then checking the large snapshot name in the '.snap'
directory of a subdirectory.

Cheers,
-- 
Luís

> I kept this patch in the testing branch but not including it for 7.1
> pending further investigation.
>
> [1] https://github.com/ceph/ceph/pull/45312
>
> Thanks,
>
>                 Ilya