linux-kernel - Re: [PATCH] sched/topology: Use kcalloc() in sched_init

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: <xhsmhcy8fln00.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Thu, 28 Aug 2025 13:11:11 +0200
From: Valentin Schneider <vschneid@...hat.com>
To: Qianfeng Rong <rongqianfeng@...o.com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann
 <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben
 Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
 linux-kernel@...r.kernel.org
Cc: Qianfeng Rong <rongqianfeng@...o.com>
Subject: Re: [PATCH] sched/topology: Use kcalloc() in sched_init_numa()

On 21/08/25 22:08, Qianfeng Rong wrote:
> Replace kzalloc() with kcalloc() in sched_init_numa().  As noted in
> the kernel documentation [1], open-coded multiplication in allocator
> arguments is discouraged because it can lead to integer overflow.
>

Hm, checkpatch does warn about these.

> Use kcalloc() to gain built-in overflow protection, making memory
> allocation safer when calculating allocation size compared to explicit
> multiplication. Similarly, use size_add() instead of explicit addition
> for 'i + nr_levels + 1'.
>
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> #1

This document is actually in the kernel sources, it would be better to
reference it as:

  Documentation/process/deprecated.rst

> @@ -1994,8 +1994,8 @@ void sched_init_numa(int offline_node)
>       /* Compute default topology size */
>       for (i = 0; sched_domain_topology[i].mask; i++);
>
> -	tl = kzalloc((i + nr_levels + 1) *
> -			sizeof(struct sched_domain_topology_level), GFP_KERNEL);
> +	tl = kcalloc(size_add(size_add(i, nr_levels), 1),
> +		     sizeof(struct sched_domain_topology_level), GFP_KERNEL);

@nr_levels is at most 256 (including illegal values between 0 and 9); @i is
going to be the size of sched_domain_topology[]; is the double size_add()
really warranted here?

>       if (!tl)
>               return;
>
> --
> 2.34.1