netdev - Re: [PATCH] division-by-zero in inet_csk_get

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 Oct 2007 14:49:02 +0200
From:	Anton Arapov <aarapov@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] division-by-zero in inet_csk_get_port

David Miller <davem@...emloft.net> writes:
> From: Anton Arapov <aarapov@...hat.com>
> Date: Wed, 10 Oct 2007 11:56:23 +0200
>
>>   Yep, that's exactly I'm talking about. I'm sure that 
>>   [...] % (high - low) [...] erroneous from the begining, because
>> in such places we want to have 1 in denominator, for the cases when we
>> have only one port. Because 34000 34000 in sysctl's
>> ip_local_port_range means 1(one) port, not 0(zero).
>> 
>>   So it seems to me that we have to fix mentioned denominators in
>> kernel/net to have 1, that will be correct logically. And do the
>> MAX<MIN check in sysctl code.
>>   From this point of view, it's best idea to have two patches: one for
>> the kernel/net denominators and another one for the sysctl.c's
>> function dointvec_minmax(). Because they can live independently. And
>> the patch for the kernel/net will do the work at least because we
>> prevent kernel trap at all.
>>   
>>   Dave, am I right?
>
> Sure, two patches is fine.

  I have been mistaken. We can't modify sysctl code itself to do the
checks like (MAX_VAL < MIN_VAL), we have generic functions, and if we
want implement something like this we have to implement absolutely new
functionality, it's insane to do it. :)
  It seems to me, all we can is to make this check in code where the
MAX_VAL<MINVAL condition brakes logic.
  FTOH the patch that prevents do_divide_error trap is
enough... Kernel will keep working, with huge kernel panic notice in
dmesg. :)
  So, now the way suggested by Denis looks reasonable.

  What do you think?

-- 
Anton Arapov, <aarapov@...hat.com>
Kernel Development, Red Hat
GPG Key ID: 0x6FA8C812

Content of type "application/pgp-signature" skipped