linux-kernel - Re: Re: [PATCH v2] sched: Fix implicit type conversion

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

Message-Id: <1635168581-2426805-1-git-send-email-jiasheng@iscas.ac.cn>
Date:   Mon, 25 Oct 2021 13:29:41 +0000
From:   Jiasheng Jiang <jiasheng@...as.ac.cn>
To:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com
Cc:     linux-kernel@...r.kernel.org, Jiasheng Jiang <jiasheng@...as.ac.cn>
Subject: Re: Re: [PATCH v2] sched: Fix implicit type conversion

On Mon, Oct 25, 2021 at 12:43:55AM +0000, Peter Zijlstra wrote:
>> The variable 'n' is defined as ULONG. However in the cpumask_next(),
>> it is used as INT.
>> That is vulnerable and may cause overflow.
>> For example, if the value of 'n' is (2^31 - 1), then it can pass the

>That would need nr_cpu_ids to be that large. How's that going to happen?

First, maybe it is hard to exploit it now, but who knows the future.
Second, the patch cost much less than the loss caused by the unexpected
input.
Third, it is universally accepted that the implicit type conversion is
vulnerable. Therefore, it will set an example for others that having
the good programming custom.