Re: KASAN: use-after-free Read in rtnetlink_put_metrics

[Sabrina Dubroca <sd@queasysnail.net>]

2018-08-01, 11:46:36 -0700, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 31 Jul 2018 16:03:13 -0700
> 
> > Looks like this commit is completely unnecessary,
> > fib6_drop_pcpu_from() calls fib6_info_release()
> > which calls fib6_info_destroy_rcu(), so this metrics
> > will be released twice...
> 
> And even if there was a leak here, it's illegal to free this
> metrics memory synchronously since it is RCU protected.

Yeah, I noticed that today, but I don't think that's the problem we're
seeing here.

> That's why it normally goes through fib6_info_destroy_rcu().
> 
> Sabrina, I'm going to revert your changes unless I see some
> progress here by the end of today.

Yeah, I'm fine with a revert, we can fix the leak later.


syzbot hasn't found a reproducer so I'm not sure it's the same issue,
but I ran into this: we can create a route, start using it, and then
give it some metrics. In that case, we'll hit rt6_set_from() with the
default metrics, so we don't refcount them. Then fib6_metric_set()
will assign the new metrics to the parent route.
Then fib6_drop_pcpu_from will see that the parent route has
non-default metrics, and try to release this, but the percpu copy
doesn't actually hold a reference. Bandaid would be to put a
DST_METRICS_REFCOUNTED check in fib6_drop_pcpu_from().

Looking at rt6_set_from(), it seems we can also do dst_init_metrics
with the old metrics, then refcount the new metrics.

And I'm not sure whether the refcount_set in fib6_metric_set() can't
be reordered so that rt6_set_from() might see the new metrics pointer,
increment the refcount, then fib6_metric_set() would do its
refcount_set, stepping over the previous increment.

-- 
Sabrina