netdev - Re: problem with rtnetlink 'reference' count

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]

Message-ID: <20171024083338.GL3165@worktop.lehotels.local>
Date:   Tue, 24 Oct 2017 10:33:38 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Florian Westphal <fw@...len.de>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: problem with rtnetlink 'reference' count

On Mon, Oct 23, 2017 at 09:37:03PM +0200, Florian Westphal wrote:

> > OK, so then why not do something like so?
> > @@ -260,10 +259,18 @@ void rtnl_unregister_all(int protocol)
> >  	RCU_INIT_POINTER(rtnl_msg_handlers[protocol], NULL);
> >  	rtnl_unlock();
> >  
> > +	/*
> > +	 * XXX explain what this is for...
> > +	 */
> >  	synchronize_net();
> >  
> > -	while (refcount_read(&rtnl_msg_handlers_ref[protocol]) > 1)
> > -		schedule();
> > +	/*
> > +	 * This serializes against the rcu_read_lock() section in
> > +	 * rtnetlink_rcv_msg() such that after this, all prior instances have
> > +	 * completed and future instances must observe the NULL written above.
> > +	 */
> > +	synchronize_rcu();
> 
> Yes, but that won't help with running dumpers, see below.
> 
> > @@ -4218,7 +4223,6 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> >  			};
> >  			err = netlink_dump_start(rtnl, skb, nlh, &c);
> 
> This will copy .dumper function address to nlh->cb for later invocation
> when dump gets resumed (its called from netlink_recvmsg()),
> so this can return to userspace and dump can be resumed on next recv().
> 
> Because the dumper function was stored in the socket, NULLing the
> rtnl_msg_handlers[] only prevents new dumps from starting but not
> already set-up dumps from resuming.

but netlink_dump_start() will actually grab a reference on the module;
but it does so too late.

Would it not be sufficient to put that try_module_get() under the
rcu_read_lock()?