Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1570432
| From | Cong Wang <xiyou.wangcong@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: net: suspicious RCU usage in nf_hook |
| Date | 2017-01-31 07:30 +0100 |
| Message-ID | <t5A70-5JM-19@gated-at.bofh.it> (permalink) |
| References | <t4mSt-1o8-3@gated-at.bofh.it> <t4orf-2aJ-1@gated-at.bofh.it> <t4pGG-35v-11@gated-at.bofh.it> <t4q9H-3hQ-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: >> > Oh well, I forgot to submit the official patch I think, Jan 9th. >> > >> > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >> > >> >> Hmm, but why only fragments need skb_orphan()? It seems like >> any kfree_skb() inside a nf hook needs to have a preceding >> skb_orphan(). > > >> >> Also, I am not convinced it is similar to commit 8282f27449bf15548 >> which is on RX path. > > Well, we clearly see IPv6 reassembly being part of the equation in both > cases. Yeah, of course. My worry is that this problem is more than just IPv6 reassembly. > > I was replying to first part of the splat [1], which was already > diagnosed and had a non official patch. > > use after free is also a bug, regardless of jump label being used or > not. > > I still do not really understand this nf_hook issue, I thought we were > disabling BH in netfilter. It is a different warning from use-after-free, this one is about sleep in atomic context, mutex lock is acquired with RCU read lock held. > > So the in_interrupt() check in net_disable_timestamp() should trigger, > this was the intent of netstamp_needed_deferred existence. > > Not sure if we can test for rcu_read_lock() as well. > The context is process context (TX path before hitting qdisc), and BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this makes me thinking maybe we really need to disable BH in this case for nf_hook()? But it is called in RX path too, and BH is already disabled there.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
net: suspicious RCU usage in nf_hook Dmitry Vyukov <dvyukov@google.com> - 2017-01-27 23:10 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-01-28 00:30 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-01-28 00:40 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-01-28 00:50 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-01-28 02:10 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-01-28 02:40 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-01-31 07:30 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-01-31 16:50 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-01 22:00 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-01 22:20 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-01 22:30 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-02 00:40 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <edumazet@google.com> - 2017-02-02 00:50 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-02 01:00 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-02 19:10 +0100
csiph-web