netdev - Re: KASAN: use-after-free Read in rtnetlink_put

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]

Date:   Wed, 1 Aug 2018 21:26:39 +0200
From:   Sabrina Dubroca <sd@...asysnail.net>
To:     David Miller <davem@...emloft.net>
Cc:     xiyou.wangcong@...il.com, eric.dumazet@...il.com,
        syzbot+41f9c04b50ef70c66947@...kaller.appspotmail.com,
        christian.brauner@...ntu.com, dsahern@...il.com, fw@...len.de,
        jbenc@...hat.com, ktkhai@...tuozzo.com,
        linux-kernel@...r.kernel.org, lucien.xin@...il.com,
        netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: use-after-free Read in rtnetlink_put_metrics

2018-08-01, 11:46:36 -0700, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@...il.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