linux-kernel - Re: [PATCH] fscrypt: Fix uninit-value in ovl_fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260124182547.GA2762@quark>
Date: Sat, 24 Jan 2026 10:25:47 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Qing Wang <wangqing7171@...il.com>
Cc: tytso@....edu, jaegeuk@...nel.org, linux-fscrypt@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	syzbot+d130f98b2c265fae5297@...kaller.appspotmail.com
Subject: Re: [PATCH] fscrypt: Fix uninit-value in ovl_fill_real

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