Re: [RFC] odd check in ceph_encode_encrypted_dname()

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Feb 17, 2025 at 10:04:50PM +0000, Viacheslav Dubeyko wrote:

> [  326.477120] This frame has 1 object:
> [  326.477466]  [32, 287) 'buf'

> (gdb) l *ceph_encode_encrypted_dname+0x4a5
> 0xffffffff829d6605 is in ceph_encode_encrypted_dname (fs/ceph/crypto.c:273).
> 268		u32 len;
> 269		int name_len = elen;
> 270		int ret;
> 271		u8 *cryptbuf = NULL;
> 272	
> 273		buf[elen] = '\0';

Cute...  The fix is obvious (should be
                        char buf[NAME_MAX + 1];
rather than
                        char buf[NAME_MAX];
), but the funny part is that it had been a bug all along -
if you give the mainline a name that has a 255-character component
that happens to start with _, you'll get buf[] filled with a copy
of that component (no NUL in sight) and have it passed as 'name' to
parse_longname() that starts with

        /* Skip initial '_' */
	name++;
	name_end = strrchr(name, '_');

See the problem?  strrchr() expects a NUL-terminated string; giving it an
array that has no zero bytes in it is an UB.

That one is -stable fodder on its own, IMO...