linux-kernel - Re: nct6775: UBSAN: shift exponent 32 is too large for 32-bit type 'long unsigned int'

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]

Date:   Wed, 13 Jun 2018 08:57:58 +0200
From:   Paul Menzel <pmenzel+linux-hwmon@...gen.mpg.de>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: nct6775: UBSAN: shift exponent 32 is too large for 32-bit type
 'long unsigned int'

Dear Guenter,


Am 13.06.2018 um 00:12 schrieb Guenter Roeck:

> On Tue, Jun 12, 2018 at 11:50:45PM +0200, Paul Menzel wrote:

>> Building Linux with the undefined behavior sanitizer (UBSAN), loading the
>> module *nct6775* on the ASRock E350M1 shows the error below.
>>
>> ```
>> [   28.322775] UBSAN: Undefined behaviour in drivers/hwmon/nct6775.c:4179:27
>> [   28.322833] shift exponent 32 is too large for 32-bit type 'long unsigned int'
>> ```
>>
>> I believe this was introduced by commit cc66b3038254 (hwmon: (nct6775)
>> Rework temperature source and label handling), but the same issue was
>> already present before.
> 
> I don't think so. The code used to be
> 	for (i = 0; i < data->temp_label_num - 1; i++) {
> Notice the "- 1". So it should be
> 	for (i = 0; i < 31; i++) {
> 
> In practice it doesn't matter because "data->temp_mask & BIT(31 + 1)"
> will always be false, causing the last loop iteration to abort, but
> it is nevertheless wrong.
> 
> Thanks a lot for the report. I'll prepare a patch.

Thank you for the instant response. I tested your proposed change, and, 
as expected, the error is gone.


Kind regards,

Paul