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...
