> -----Original Message----- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Jon Maloy > Sent: Monday, December 04, 2017 14:50 > To: Cong Wang <xiyou.wangc...@gmail.com>; David Miller > <da...@davemloft.net> > Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>; tipc- > discuss...@lists.sourceforge.net; Ying Xue <ying....@windriver.com> > Subject: RE: [Patch net v2] tipc: fix a null pointer deref on error path > > > > > -----Original Message----- > > From: Cong Wang [mailto:xiyou.wangc...@gmail.com] > > Sent: Monday, December 04, 2017 14:41 > > To: David Miller <da...@davemloft.net> > > Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>; tipc- > > discuss...@lists.sourceforge.net; Jon Maloy <jon.ma...@ericsson.com>; > > Ying Xue <ying....@windriver.com> > > Subject: Re: [Patch net v2] tipc: fix a null pointer deref on error > > path > > > > On Mon, Dec 4, 2017 at 11:23 AM, Cong Wang > <xiyou.wangc...@gmail.com> > > wrote: > > > On Mon, Dec 4, 2017 at 10:57 AM, David Miller <da...@davemloft.net> > > wrote: > > >> > > >> It looks like tipc_accept_from_sock() has a similar problem? The > > >> tipc_close_conn() will get invoked indirectly from the > > >> sock_release() path right? > > > > > > Not sure, the sock_release() in tipc_accept_from_sock() is for > > > kernel_accept(), not for tipc_alloc_conn(). Or maybe it is hiding > > > deep in the call chain that I miss? > > > > I see: > > > > tipc_release() -> tipc_sk_leave() -> tipc_group_delete() > > -> tipc_topsrv_kern_unsubscr() -> tipc_close_conn() > > > > Seems on this path we do need to skip NULL too. > > You are right. The right solution is to just call conn_put() twice here. > I already have a patch ready for this, but it is part of a series that needs > more > review. > I should probably post it separately...
Well, calling conn_put() twice was ok in my series, but in the current upstream version it is not enough. I will find a different short term solution. ///jon > > ///jon
