linux-kernel - Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data

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: <20251210022202.GB4128@sol>
Date: Tue, 9 Dec 2025 18:22:02 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: syzbot <syzbot+7add5c56bc2a14145d20@...kaller.appspotmail.com>
Cc: davem@...emloft.net, herbert@...dor.apana.org.au, jaegeuk@...nel.org,
	linux-crypto@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-fscrypt@...r.kernel.org, linux-kernel@...r.kernel.org,
	syzkaller-bugs@...glegroups.com, tytso@....edu
Subject: Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in
 fscrypt_crypt_data_unit

On Tue, Dec 09, 2025 at 03:08:17AM -0800, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    a110f942672c Merge tag 'pinctrl-v6.19-1' of git://git.kern..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17495992580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=10d58c94af5f9772
> dashboard link: https://syzkaller.appspot.com/bug?extid=7add5c56bc2a14145d20
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1122aec2580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14012a1a580000

Simplified reproducer:

    rm -f image
    mkdir -p mnt
    mkfs.ext4 -O encrypt -b 1024 image 1M
    mount image mnt -o test_dummy_encryption
    dd if=/dev/urandom of=mnt/file bs=1 seek=1024 count=1
    sync

It causes ext4 to encrypt uninitialized memory:

    BUG: KMSAN: uninit-value in crypto_aes_encrypt+0x511b/0x5260
    [...]
    fscrypt_encrypt_pagecache_blocks+0x309/0x6c0
    ext4_bio_write_folio+0xd2f/0x2210
    [...]

ext4_bio_write_folio() has:

	/*
	 * If any blocks are being written to an encrypted file, encrypt them
	 * into a bounce page.  For simplicity, just encrypt until the last
	 * block which might be needed.  This may cause some unneeded blocks
	 * (e.g. holes) to be unnecessarily encrypted, but this is rare and
	 * can't happen in the common case of blocksize == PAGE_SIZE.
	 */
	if (fscrypt_inode_uses_fs_layer_crypto(inode)) {
		gfp_t gfp_flags = GFP_NOFS;
		unsigned int enc_bytes = round_up(len, i_blocksize(inode));

So I think that if a non-first block in a page is being written to disk
and all preceding blocks in the page are holes, the (uninitialized)
sections of the page corresponding to the holes are being encrypted too.

This is probably "benign", as ext4 doesn't do anything with the
encrypted uninitialized data.  (Also note that this issue can occur only
when block_size < PAGE_SIZE.)

I'm not yet sure how to proceed here.  We could make ext4 be more
selective about encrypting the exact set of blocks in the page that are
being written.  That would require support in fs/crypto/ for that.  We
could use kmsan_unpoison_memory() to just suppress the warning.

Or, we could go forward with removing support for the "fs-layer crypto"
from ext4 and only support blk-crypto (relying on blk-crypto-fallback
for the software fallback).  The blk-crypto code path doesn't have this
problem since it more closely ties the encryption to the actual write.
It also works better with folios.

- Eric