netdev - Number IPv6 routing entries are growing without limit when processing routing advertisements

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: <7aebcea5-bf28-e31c-39b1-f3de45b8df41@secunet.com>
Date:   Fri, 26 Jun 2020 13:30:32 +0200
From:   Torsten Hilbrich <torsten.hilbrich@...unet.com>
To:     <netdev@...r.kernel.org>
CC:     "David S. Miller" <davem@...emloft.net>,
        David Ahern <dsahern@...il.com>
Subject: Number IPv6 routing entries are growing without limit when processing
 routing advertisements

Please CC me on replies

Hello,

a colleague of mine detected that a kernel since version 4.17 does not limit the number of IPv6 routing entries when processing routing advertisements.

I checked it now with a kernel based on v5.4.42 and could confirm this behavior. The configuration setting are as the following:

- net.ipv6.route.max_size: default setting 4096
- net.ipv6.route.gc_thres: default setting 1024
- net.ipv6.conf.eth0.accept_ra: 2
- net.ipv6.conf.eth0.accept_redirect: 1
- net.ipv6.conf.eth0.disable_ipv6: 0

The test is running the tool atk6-flood_router26 (from debian package thc-ipv6) from another machine connected via LAN on eth0. This tool when sent about 16000 routing advertisement per second in my test setup. The lifetime of the resulting routing entries seems to be about 130,000s. The default routes added have a lifetime of 65,535s.

The test shows the following:

- for every routing advertisement a new default route entry is added by ndisc_router_discovery
- the limit set by net.ipv6.route.max_size is not honored, even after a single second I have these 16000 routing entries
- after a view minutes of testing I can easily have millions of routing entries
- the free memory is reduced with a speed of about 1.2 MByte/s

I assume that the code changes regarding dst entries and fib6 entries which has been completed with commits:

commit 8d1c802b2815edc97af8a58c5045ebaf3848621a
Author: David Ahern <dsahern@...il.com>
Date:   Tue Apr 17 17:33:26 2018 -0700

    net/ipv6: Flip FIB entries to fib6_info

    Convert all code paths referencing a FIB entry from
    rt6_info to fib6_info.

    Signed-off-by: David Ahern <dsahern@...il.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

commit 93531c6743157d7e8c5792f8ed1a57641149d62c
Author: David Ahern <dsahern@...il.com>
Date:   Tue Apr 17 17:33:25 2018 -0700

    net/ipv6: separate handling of FIB entries from dst based routes

    Last step before flipping the data type for FIB entries:
    - use fib6_info_alloc to create FIB entries in ip6_route_info_create
      and addrconf_dst_alloc
    - use fib6_info_release in place of dst_release, ip6_rt_put and
      rt6_release
    - remove the dst_hold before calling __ip6_ins_rt or ip6_del_rt
    - when purging routes, drop per-cpu routes
    - replace inc and dec of rt6i_ref with fib6_info_hold and fib6_info_release
    - use rt->from since it points to the FIB entry
    - drop references to exception bucket, fib6_metrics and per-cpu from
      dst entries (those are relevant for fib entries only)

    Signed-off-by: David Ahern <dsahern@...il.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

might have changed the behavior here. Before these commits the max_size has been checked by ip6_dst_gc. It seems that this code path is gone now.

I already checked the gc support for fib6. It seems that this is regularly run (about every 30 seconds by default) and removes entries which lifetime has expired.  This is not sufficient for such an Denial of Service attack.

Any ideas on the problem?

Thanks,

	Torsten