linux-kernel - Re[2]: [PATCH] fork_init: fix division by zero

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]

Date:	Wed, 10 Dec 2008 13:01:13 +0300
From:	Yuri Tikhonov <yur@...raft.com>
To:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
CC:	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
	Detlev Zundel <dzu@...x.de>, Wolfgang Denk <wd@...x.de>,
	Milton Miller <miltonm@....com>, Ilya Yanok <yanok@...raft.com>
Subject: Re[2]: [PATCH] fork_init: fix division by zero


 Hello Geert,

On Wednesday, December 10, 2008 you wrote:
> On Tue, 9 Dec 2008, Yuri Tikhonov wrote:
>> The following patch fixes divide-by-zero error for the
>> cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
>> Support for such big page sizes on 44x is not present in the
>> current kernel yet, but coming soon.
>> 
>> Also this patch fixes the comment for the max_threads
>> settings, as this didn't match the things actually done
>> in the code.
>> 
>> Signed-off-by: Yuri Tikhonov <yur@...raft.com>
>> Signed-off-by: Ilya Yanok <yanok@...raft.com>
>> ---
>>  kernel/fork.c |    8 ++++++--
>>  1 files changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 2a372a0..b0ac2fb 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -181,10 +181,14 @@ void __init fork_init(unsigned long mempages)
>>  
>>       /*
>>        * The default maximum number of threads is set to a safe
>> -      * value: the thread structures can take up at most half
>> -      * of memory.
>> +      * value: the thread structures can take up at most
>> +      * (1/8) part of memory.
>>        */
>> +#if (8 * THREAD_SIZE) > PAGE_SIZE
>>       max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
>> +#else
>> +     max_threads = mempages * PAGE_SIZE / (8 * THREAD_SIZE);
>                       ^^^^^^^^^^^^^^^^^^^^
>> +#endif

> Can't this overflow, e.g. on 32-bit machines with HIGHMEM?

 The multiplier here is not PAGE_SIZE, but [PAGE_SIZE / (8 * 
THREAD_SIZE)], and this value is expected to be rather small (2, 4, or 
so).

 Furthermore, due to the #if/#endif construction multiplication is 
used only with rather big PAGE_SIZE values, and the bigger page size 
is then the smaller 'mempages' is.

 So, for example, when running with PAGE_SIZE=256KB, THREAD_SIZE=8KB, 
on 32-bit 440spe-based machine with 4GB RAM installed, here we have:

 max_threads = (4G/256K) * (256K / 8 * 8K) = 16384 * 4 = 65536.

 And the overflow will have a place only in case of very very big 
sizes of RAM: >= 256TB:

 max_threads = (256T / 256K) * (256K / 8 * 8K) = 0x4000.0000 * 4.

 But I don't think that with 256TB RAM installed this code will be 
the only place of problems :)

 Regards, Yuri

 --
 Yuri Tikhonov, Senior Software Engineer
 Emcraft Systems, www.emcraft.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/