Re: [PATCH] fscrypt: Fix uninit-value in ovl_fill_real

[Eric Biggers]

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: syzbot+d130f98b2c265fae5297@xxxxxxxxxxxxxxxxxxxxxxxxx
> Close: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297
> Signed-off-by: Qing Wang <wangqing7171@xxxxxxxxx>
> ---
>  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