linux-kernel - Re: [PATCH] hfsplus: fix uninit-value in hfsplus

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADhLXY5pVdqhY+cLze66UrZmy0saCro_mQR+APth+VC5tMEnjA@mail.gmail.com>
Date: Wed, 21 Jan 2026 11:56:09 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@....com>
Cc: "glaubitz@...sik.fu-berlin.de" <glaubitz@...sik.fu-berlin.de>, "frank.li@...o.com" <frank.li@...o.com>, 
	"slava@...eyko.com" <slava@...eyko.com>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"syzbot+d80abb5b890d39261e72@...kaller.appspotmail.com" <syzbot+d80abb5b890d39261e72@...kaller.appspotmail.com>
Subject: Re: [PATCH] hfsplus: fix uninit-value in hfsplus_strcasecmp

On Wed, Jan 21, 2026 at 3:59 AM Viacheslav Dubeyko
<Slava.Dubeyko@....com> wrote:

> Frankly speaking, I don't quite follow what is wrong with current logic from
> your explanation. Only, struct hfsplus_cat_thread contains nodeName string. And
> hfsplus_strcasecmp() can try to compare some strings only for Catalog thread
> type. But hfs_brec_read() should read namely only this type of Catalog File
> record. So, I cannot imagine how likewise issue could happen. Could you explain
> the issue more clearly? How uninitiliazed nodeName strings can be used for
> comparison? How does it happened? Because, struct hfsplus_cat_thread is the
> biggest item in hfsplus_cat_entry union. The struct hfsplus_cat_file and struct
> hfsplus_cat_folder don't contain any strings and strings cannot be used for
> comparison in these structures case. But struct hfsplus_cat_thread should be
> read completely with the string.

Hi Slava,

Thank you for the review.

Regarding your question about how uninitialized data is used: You're correct
that in normal operation, hfs_brec_read() should fully read the catalog
thread record. However, the KMSAN report from syzbot shows that uninitialized
data is being accessed.

Looking at the code flow and the KMSAN stack trace:
1. tmp is declared on the stack without initialization in hfsplus_find_cat()
2. hfs_brec_read() is called to fill it from disk
3. With a corrupted/malformed filesystem image (which syzbot fuzzes),
   hfs_brec_read() may read partial or invalid data
4. The tmp.thread.nodeName.unicode array may not be fully populated
5. hfsplus_cat_build_key_uni() copies from this array based on nodeName.length
6. hfsplus_strcasecmp() then reads these bytes and passes them to case_fold()
7. case_fold() uses the value as an array index: hfsplus_case_fold_table[c >> 8]
8. KMSAN detects this uninitialized value being used as an array index

The KMSAN report explicitly shows the uninit-value originates from the
uninitialized tmp variable and propagates through the code path. The
initialization ensures that even with corrupted filesystem images, we use
zeros instead of random stack data.

Syzbot has confirmed that the fix resolves the issue:
https://syzkaller.appspot.com/bug?extid=d80abb5b890d39261e72

I will update the patch to use = {0} initialization as you suggested.

Thanks,
Deepanshu