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 <redacted>
Reported-by: Fengguang Wu <redacted>
---
net/ipv4/fib_frontend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 <redacted>
Reported-by: Fengguang Wu <redacted>
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.
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 <redacted>
Reported-by: Fengguang Wu <redacted>
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
On Tue, Dec 19, 2017 at 09:34:16AM -0800, Alexander Duyck wrote:
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.
I decided to go with the original patch because it resulted in a very
small diff (patch is needed in -stable as well), but I agree with Dave
about it not being explicit enough.
How about I'll send v2 with a comment and then we can try Alex's
suggestion in net-next?
Thanks