In the Linux kernel, the following vulnerability has been resolved:

hfs: fix KMSAN uninit-value issue in hfsfindsetzerobits()

The syzbot reported issue in hfsfindsetzerobits():

===================================================== BUG: KMSAN: uninit-value in hfsfindsetzerobits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfsfindsetzerobits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfsvbmsearchfree+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfsextendfile+0x6a5/0x1b00 fs/hfs/extent.c:408 hfsget_block+0x435/0x1150 fs/hfs/extent.c:353 __blockwritebeginint+0xa76/0x3030 fs/buffer.c:2151 blockwritebegin fs/buffer.c:2262 [inline] contwritebegin+0x10e1/0x1bc0 fs/buffer.c:2601 hfswritebegin+0x85/0x130 fs/hfs/inode.c:52 contexpandzero fs/buffer.c:2528 [inline] contwritebegin+0x35a/0x1bc0 fs/buffer.c:2591 hfswritebegin+0x85/0x130 fs/hfs/inode.c:52 hfsfiletruncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfsinodesetattr+0x964/0xaa0 fs/hfs/inode.c:654 notifychange+0x1993/0x1aa0 fs/attr.c:552 dotruncate+0x28f/0x310 fs/open.c:68 doftruncate+0x698/0x730 fs/open.c:195 dosysftruncate fs/open.c:210 [inline] __dosysftruncate fs/open.c:215 [inline] __sesysftruncate fs/open.c:213 [inline] _x64sysftruncate+0x11b/0x250 fs/open.c:213 x64syscall+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls64.h:78 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd9/0x210 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4154 [inline] slaballoc_node mm/slub.c:4197 [inline] __kmalloccachenoprof+0x7f7/0xed0 mm/slub.c:4354 kmallocnoprof include/linux/slab.h:905 [inline] hfsmdbget+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfsfillsuper+0x3d0/0xb80 fs/hfs/super.c:337 gettreebdevflags+0x6e3/0x920 fs/super.c:1681 gettreebdev+0x38/0x50 fs/super.c:1704 hfsgettree+0x35/0x40 fs/hfs/super.c:388 vfsgettree+0xb0/0x5c0 fs/super.c:1804 donewmount+0x738/0x1610 fs/namespace.c:3902 pathmount+0x6db/0x1e90 fs/namespace.c:4226 domount fs/namespace.c:4239 [inline] __dosysmount fs/namespace.c:4450 [inline] __sesysmount+0x6eb/0x7d0 fs/namespace.c:4427 _x64sysmount+0xe4/0x150 fs/namespace.c:4427 x64syscall+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls64.h:166 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd9/0x210 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025

The HFSSB(sb)->bitmap buffer is allocated in hfsmdb_get():

HFSSB(sb)->bitmap = kmalloc(8192, GFPKERNEL);

Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the "garbage", then it can affect the bitmap operations and it triggers the reported issue.

This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and "garbage" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.