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: <a1eaeddc-69df-e0fa-c06a-285c3234249c@cumulusnetworks.com>
Date:   Mon, 23 Jan 2017 09:51:07 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, xiaolong.ye@...el.com
Subject: Re: [PATCH net-next] net: ipv6: ignore null_entry on route dumps

On 1/22/17 9:58 PM, David Miller wrote:
> 
> David, please slow down.
> 
> How is the NULL entry getting selected to be dumped and passed
> down here in the first place?

The null_entry might be a 'marker' but is integral to the ipv6 fib. For starters:

static int __net_init fib6_net_init(struct net *net)
{
...
        net->ipv6.fib6_main_tbl = kzalloc(sizeof(*net->ipv6.fib6_main_tbl),
                                          GFP_KERNEL);
...
        net->ipv6.fib6_main_tbl->tb6_id = RT6_TABLE_MAIN;
        net->ipv6.fib6_main_tbl->tb6_root.leaf = net->ipv6.ip6_null_entry;

...


Same goes for every other table allocated:

static struct fib6_table *fib6_alloc_table(struct net *net, u32 id)
{
        struct fib6_table *table;

        table = kzalloc(sizeof(*table), GFP_ATOMIC);
        if (table) {
                table->tb6_id = id;
                table->tb6_root.leaf = net->ipv6.ip6_null_entry;
..
        }


And if you look at the fib6_add code:

                        sfn->leaf = info->nl_net->ipv6.ip6_null_entry;
                        atomic_inc(&info->nl_net->ipv6.ip6_null_entry->rt6i_ref);
                        sfn->fn_flags = RTN_ROOT;
                        sfn->fn_sernum = sernum;

                        /* Now add the first leaf node to new subtree */

                        sn = fib6_add_1(sfn, &rt->rt6i_src.addr,
                                        rt->rt6i_src.plen,
                                        offsetof(struct rt6_info, rt6i_src),
                                        allow_create, replace_required, sernum);

Meaning that a walk of the table is going to dump the ip6_null_entry route, potentially multiple times.

As far as the dump request the chain rtnetlink message invokes inet6_dump_fib:

inet6_dump_fib
- fib6_dump_table
  + fib6_walk
    * fib6_walk_continue
      - fib6_dump_node
        + rt6_dump_route

Seems to me the most appropriate place to check that rt is the null_entry route is rt6_dump_route but perhaps fib6_dump_node could as well. This patch buts the check in rt6_dump_route. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ