netdev - Re: [PATCH net] ipv4: Fix use-after-free when flushing FIB tables

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: <CAKgT0UfnK9ueT3PtD=HKB2f_XhccoVq6HnnQ=vRgEdtM-WUG2Q@mail.gmail.com>
Date:   Tue, 19 Dec 2017 09:34:16 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Ido Schimmel <idosch@...lanox.com>,
        Netdev <netdev@...r.kernel.org>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        Fengguang Wu <fengguang.wu@...el.com>,
        David Ahern <dsahern@...il.com>, mlxsw@...lanox.com
Subject: Re: [PATCH net] ipv4: Fix use-after-free when flushing FIB tables

On Tue, Dec 19, 2017 at 8:32 AM, David Miller <davem@...emloft.net> wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> Date: Mon, 18 Dec 2017 10:13:20 +0200
>
>> Since commit 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse") the
>> local table uses the same trie allocated for the main table when custom
>> rules are not in use.
>>
>> When a net namespace is dismantled, the main table is flushed and freed
>> (via an RCU callback) before the local table. In case the callback is
>> invoked before the local table is iterated, a use-after-free can occur.
>>
>> Fix this by iterating over the FIB tables in reverse order, so that the
>> main table is always freed after the local table.
>>
>> Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
>> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
>> Reported-by: Fengguang Wu <fengguang.wu@...el.com>
>
> This is really too clever of a fix I think :-)
>
> I would prefer if we fixed things more explicitly.
>
> In struct fib_table you can add a "data_ref" integer.  Any pointer
> reference created to fib_table->__data increases this counter.  It is
> always done inside of RTNL locking, so should be doable without
> atomics or extra locking.
>
> For a non-aliased fib_table we go:
>
>         if (!--fib_table->data_ref)
>                 kfree(fib_table);
>
> And for aliased ones we do something like:
>
>         if (fib_table->tb_data != fib_table->__data) {
>                 void *data = fib_table->fb_data;
>                 struct fib_table *alias;
>
>                 alias = container_of(data, struct fib_table, __data[0]);
>                 if (!--alias->data_ref)
>                         kfree(alias);
>                 kfree(fib_table);
>         }
>
> Something like that.

That seems like unneeded complexity when the issue is just the order
that these were created in versus the order they are freed in. As long
as we always destroy the one containing the alias before the one that
has the actual data we don't need to have a reference count. Basically
the issue is the bring-up and the tear-down order. It isn't something
that really needs a reference count since it would always be either 1
or 2. My preference would be to just add a comment explaining that
local must always be destroyed before the main trie in order to
guarantee that there are no external references to the data contained
in main when it is freed.

The one question I have in all this is if I did the bring-up in the
right order in the first place. I'm wondering if local should be where
the combined trie lives instead of main. Local is currently destroyed
after main anyway so I wonder if it wouldn't have been better if
everything lived in local since from what I can tell it looks like we
add rules for local first before we do so in main. The complexity of
that patch would be higher though since the patch would need to be
much larger and touch multiple files.

- Alex