linux-kernel - Re: [syzbot] [hwmon?] KMSAN: uninit-value in get_temp

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: <61233ba1-e5ad-4d7a-ba31-3b5d0adcffcc@roeck-us.net>
Date: Thu, 19 Jun 2025 06:01:27 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Marius Zachmann <mail@...iuszachmann.de>,
 syzbot <syzbot+3bbbade4e1a7ab45ca3b@...kaller.appspotmail.com>,
 jdelvare@...e.com, linux-hwmon@...r.kernel.org,
 linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [hwmon?] KMSAN: uninit-value in get_temp_cnct

On 6/19/25 01:01, Marius Zachmann wrote:
> Am Mittwoch, dem 18.06.2025 um 22:56 -0700 schrieb Guenter Roeck:
>> On 6/18/25 21:31, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:    4774cfe3543a Merge tag 'scsi-fixes' of
>>> git://git.kernel.or..
>>> git tree:       upstream
>>> console output:
>>> https://syzkaller.appspot.com/x/log.txt?x=10e3f10c580000
>>> kernel config:
>>> https://syzkaller.appspot.com/x/.config?x=61539536677af51c
>>> dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=3bbbade4e1a7ab45ca3b
>>> compiler:       Debian clang version 20.1.6
>>> (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian
>>> LLD 20.1.6
>>> userspace arch: i386
>>>
>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>
>>
>> It doesn't need one: The problem will be seen if the data returned
>> from the
>> power supply is shorter than expected. In the example below, the
>> problem will
>> be seen if less than NUM_TEMP_SENSORS+1 data bytes were received.
>> One possible fix would be to record the returned data length in
>> ccp_raw_event()
>> and to have each caller of send_usb_cmd() check if the returned
>> amount of data
>> is sufficient.
>>
>> Guenter
> 
> The device should always return the same number of bytes.

The term is "should". That doesn't mean it always _does_ return the
expected number of bytes, only that it is expected to do so.

> I could zero-initialize the buffer at allocation. Then there should
> be no uninitialized values.

As long as the values are usable, sure. That would not really fix the
protocol error, though, it would just hide it.

> Also I could check the number of returned bytes in send_usb_cmd()
> instead of having each caller checking it, and return -EIO if
> it is not correct?
> 

Yes, that would be an even better fix, though I would suggest to return
-EPROTO in that case to distinguish it from an actual i/o error.

Thanks,
Guenter