linux-kernel - Re: Kernel-DOS error in arp mechanism – no delete off incomplete arp adresses

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, 21 Dec 2011 08:44:27 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	richard -rw- weinberger <richard.weinberger@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	Robert Gladewitz <gladewitz@....de>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Kernel-DOS error in arp mechanism – no
 delete off incomplete arp adresses

Le samedi 17 décembre 2011 à 14:26 +0100, richard -rw- weinberger a
écrit :
> On Sat, Dec 17, 2011 at 9:27 AM, Robert Gladewitz <gladewitz@....de> wrote:
> > Hello,
> >
> > first i have to say sorry for m y bad english. I try my best to descripe the
> > error.
> >
> > I Use Linux-Routers for internal and external firewall components. For this
> > I Use own kernel configurations und use only the drivers an modules what I
> > need. Other features and modules I deactivated in my kernel versions
> >
> > Since the kernel version 2.6.36 there is some mistake in the ipv4 arp
> > implementation. The the System try to find an unknown system, the send an
> > “who is” and marked the ip address as “incomplete” (German: unvollständig).
> > The thing is, usually linux delete all incomplete and complete entries in
> > some time, but in all kernel versions since 2.6.36 he doas not delete any
> > addresses.
> >
> > In my case, I scan my network-segmens for new devices (Kaspersky, Landesk)
> > and on this process, the router learned a lot of incomplete addresses. I
> > have some class b networks (from the history), and this means the router
> > will be learned mor then 2^16 adresses.
> >
> > Now the kerlen learn a maximum addresses – I know this is defined on
> > gc_thresh1 , gc_thresh2 and gc_thresh3 in the proc system under
> > sys.net.ipv4.neight.default. If the table have the maximum addresses in the
> > table (default=1024), no new host can send traffic packet over this router.
> > This means, we have a classical risk of DOS. In my case, I have only an
> > internal risk, but some providers may have also external risc.
> >
> > I hope, my description help you to find this error. I send also my kernel
> > config, may there is some relation to small configurations in kernel
> >
> > Viele Grüße
> >
> > Robert Gladewitz
> >
> 
> CC'ing netdev.
> 

Hmm, it seems we removed the ip route garbage collection too soon.

In the old times, we had a mechanism (rt_check_expire()) to remove old
route cache entries, but not anymore, so we can have some slots in IP
route cache referencing neighbours entries for infinite amount of time.

8.0.0.72 dev eth3  ref 2 used 1038/1098/1035 probes 6 FAILED
8.0.0.205 dev eth3  ref 2 used 639/699/636 probes 6 FAILED
8.0.0.82 dev eth3  ref 2 used 1008/1068/1005 probes 6 FAILED
8.0.0.215 dev eth3  ref 2 used 609/669/606 probes 6 FAILED

In 2.6.39, commit 2c8cec5c10bc (ipv4: Cache learned PMTU information in
inetpeer.) removed rt_check_expire() and added this problem.

David, I suggest we add back the garbage collector for current kernels,
we'll remove it when route cache really disappear ?

I'll send a patch today.


--
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/