AFAICS, this
/* To understand the 240 limit, see CEPH_NOHASH_NAME_MAX comments */
WARN_ON(elen > 240);
if ((elen > 0) && (dir != parent)) {
char tmp_buf[NAME_MAX];
elen = snprintf(tmp_buf, sizeof(tmp_buf), "_%.*s_%ld",
elen, buf, dir->i_ino);
memcpy(buf, tmp_buf, elen);
}
could drop the (elen > 0) part of the test. elen comes from
elen = ceph_base64_encode(cryptbuf, len, buf);
and that can't return a non-positive unless the second argument is 0 or
above 1G. The latter is flat-out impossible - right before that call
we have
/* hash the end if the name is long enough */
if (len > CEPH_NOHASH_NAME_MAX) {
u8 hash[SHA256_DIGEST_SIZE];
u8 *extra = cryptbuf + CEPH_NOHASH_NAME_MAX;
/*
* hash the extra bytes and overwrite crypttext beyond that
* point with it
*/
sha256(extra, len - CEPH_NOHASH_NAME_MAX, hash);
memcpy(extra, hash, SHA256_DIGEST_SIZE);
len = CEPH_NOHASH_NAME_MAX + SHA256_DIGEST_SIZE;
}
which obviously caps it with CEPH_NOHASH_NAME_MAX + SHA256_DIGEST_SIZE,
i.e. (180 - SHA256_DIGEST_SIZE) + SHA256_DIGEST_SIZE.
The former would have to come from
if (!fscrypt_fname_encrypted_size(dir, iname.len, NAME_MAX, &len)) {
elen = -ENAMETOOLONG;
goto out;
}
and since fscrypt_fname_encrypted_size() must've returned true, we have
len no less than FSCRYPT_FNAME_MIN_MSG_LEN, i.e. it's 16 or greater.
That stuff went into the tree in dd66df0053ef8 "ceph: add support for encrypted
snapshot names" and as far as I can tell, everything above had been applicable
back then too.
Am I missing something subtle here? Can elen be non-positive at that point?
