From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sabrina Dubroca Subject: Re: KASAN: use-after-free Read in rtnetlink_put_metrics Date: Wed, 1 Aug 2018 21:26:39 +0200 Message-ID: <20180801192639.GA30287@bistromath.localdomain> References: <20180731134014.GA32114@bistromath.localdomain> <20180801.114636.279269263935333136.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: xiyou.wangcong@gmail.com, eric.dumazet@gmail.com, syzbot+41f9c04b50ef70c66947@syzkaller.appspotmail.com, christian.brauner@ubuntu.com, dsahern@gmail.com, fw@strlen.de, jbenc@redhat.com, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, lucien.xin@gmail.com, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com To: David Miller Return-path: Content-Disposition: inline In-Reply-To: <20180801.114636.279269263935333136.davem@davemloft.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 2018-08-01, 11:46:36 -0700, David Miller wrote: > From: Cong Wang > 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