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@syzkaller.appspotmail.com
Close: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297
Signed-off-by: Qing Wang <wangqing7171@gmail.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);
 	if (!crypto_str->name)
 		return -ENOMEM;
 	crypto_str->len = max_presented_len;
-- 
2.34.1

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

On Sun, 25 Jan 2026 at 02:25, Eric Biggers wrote:
> 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 '.'.

Hi Eric,
Thanks for your reply. I agreed with your idea and resend a new patch.

https://lore.kernel.org/all/20260126062216.496560-1-wangqing7171@gmail.com/

Looking forward to your next review.

-- 
Best Regards,
Qing

Syzbot reported a KMSAN uninit-value issue in ovl_fill_real.

This iusse's call chain is:
__do_sys_getdents64()
    -> iterate_dir()
        ...
            -> ext4_readdir()
                -> fscrypt_fname_alloc_buffer() // alloc
                -> fscrypt_fname_disk_to_usr // write without tail '\0'
                -> dir_emit()
                    -> ovl_fill_real() // read by strcmp()

The string is used to store the decrypted directory entry name for an
encrypted inode. As shown in the call chain, fscrypt_fname_disk_to_usr()
write it wthout null-terminate. However, ovl_fill_real() uses strcmp() to
compare the name against "..", which assumes a null-terminated string and
may trigger a KMSAN uninit-value warning when the buffer tail contains
uninit data.

Reported-by: syzbot+d130f98b2c265fae5297@syzkaller.appspotmail.com
Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
Closes: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
---
 fs/overlayfs/readdir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index 160960bb0ad0..e852b38949b6 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -755,7 +755,7 @@ static bool ovl_fill_real(struct dir_context *ctx, const char *name,
 	struct dir_context *orig_ctx = rdt->orig_ctx;
 	bool res;
 
-	if (rdt->parent_ino && strcmp(name, "..") == 0) {
+	if (rdt->parent_ino && namelen == 2 && strncmp(name, "..", namelen) == 0) {
 		ino = rdt->parent_ino;
 	} else if (rdt->cache) {
 		struct ovl_cache_entry *p;
-- 
2.34.1

On Mon, Jan 26, 2026 at 02:22:16PM +0800, Qing Wang wrote:
> ---
>  fs/overlayfs/readdir.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This is an overlayfs patch, so please title it appropriately and use
get_maintainer.pl to get the correct recipients.  You can leave
linux-fscrypt@vger.kernel.org on Cc.

- Eric

On Tue, 27 Jan 2026 at 11:47, Eric Biggers <ebiggers@kernel.org> wrote:
> This is an overlayfs patch, so please title it appropriately and use
> get_maintainer.pl to get the correct recipients.  You can leave
> linux-fscrypt@vger.kernel.org on Cc.

Thank you again for your guidance.

--
Best regards,
Qing