On Fri, Jan 23, 2026 at 03:30:37PM +0800, Qing Wang wrote:
> Syzbot reported a KMSAN uninit-value issue in ovl_fill_real and it was
> allocated from fscrypt_fname_alloc_buffer. Fixed it by kzalloc.
>
> The call chain is:
> __do_sys_getdents64()
> -> iterate_dir()
> ...
> -> ext4_readdir()
> -> fscrypt_fname_alloc_buffer() // alloc
> -> dir_emit()
> -> ovl_fill_real() // use by strcmp()
>
> Reported-by: [email protected]
> Close: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297
> Signed-off-by: Qing Wang <[email protected]>
> ---
> fs/crypto/fname.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
> index a9a4432d12ba..ba8282b96a2e 100644
> --- a/fs/crypto/fname.c
> +++ b/fs/crypto/fname.c
> @@ -220,7 +220,7 @@ int fscrypt_fname_alloc_buffer(u32 max_encrypted_len,
> u32 max_presented_len = max_t(u32, FSCRYPT_NOKEY_NAME_MAX_ENCODED,
> max_encrypted_len);
>
> - crypto_str->name = kmalloc(max_presented_len + 1, GFP_NOFS);
> + crypto_str->name = kzalloc(max_presented_len + 1, GFP_NOFS);
For KMSAN issues, it's important to root-cause them.
Zero-initialization isn't necessarily the right fix.
In this case, it looks like ovl_fill_real() is incorrectly assuming that
the name is NUL-terminated.
Yet, the name passed to dir_context::actor isn't normally
NUL-terminated. Even for a regular directory, ext4 just passes a
pointer to the filename in the ext4_dir_entry_2 in the buffer cache.
The encrypted directory case doesn't seem to be fundamentally different.
Just KMSAN is able to report the issue because the memory is in a slab
buffer rather than the buffer cache.
Can you consider fixing ovl_fill_real()? Instead of strcmp(".."), it
should check whether namelen is 2 and the first two chars are '.'.
- Eric
