Hi, On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote:> On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the >> process continues and calls INP_WUNLOCK() here: >> >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > Look also to sys/netinet/tcp_timewait.c:488 > > And check other locks from r160549You are right, and here the a fix proposal for this issue: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped https://reviews.freebsd.org/D8211 It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED inpcb should never be proceed further. Slawa, as you are the only one to reproduce this issue currently, could test this patch? (And remove the temporary patch I did provided to you before). I will wait for your tests results before pushing further. Thanks! diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index c72f01f..37f27e0 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -921,6 +921,16 @@ findpcb: goto dropwithreset; } INP_WLOCK_ASSERT(inp); + /* + * While waiting for inp lock during the lookup, another thread + * can have droppedt the inpcb, in which case we need to loop back + * and try to find a new inpcb to deliver to. + */ + if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; + } if ((inp->inp_flowtype == M_HASHTYPE_NONE) && (M_HASHTYPE_GET(m) != M_HASHTYPE_NONE) && ((inp->inp_socket == NULL) || @@ -981,6 +991,10 @@ relocked: if (in_pcbrele_wlocked(inp)) { inp = NULL; goto findpcb; + } else if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; } } else ti_locked = TI_RLOCKED; @@ -1040,6 +1054,10 @@ relocked: if (in_pcbrele_wlocked(inp)) { inp = NULL; goto findpcb; + } else if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; } goto relocked; } else -- Julien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20161010/d072206b/attachment.sig>
On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote:> > Hi, > > On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > > > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the > >> process continues and calls INP_WUNLOCK() here: > >> > >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > > > Look also to sys/netinet/tcp_timewait.c:488 > > > > And check other locks from r160549 > > You are right, and here the a fix proposal for this issue: > > Fix a double-free when an inp transitions to INP_TIMEWAIT state after > having been dropped > https://reviews.freebsd.org/D8211 > > It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED > inpcb should never be proceed further. > > Slawa, as you are the only one to reproduce this issue currently, could > test this patch? (And remove the temporary patch I did provided to you > before). > > I will wait for your tests results before pushing further.OK, I am will try it tomorrow Thanks!> Thanks! > > diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c > index c72f01f..37f27e0 100644 > --- a/sys/netinet/tcp_input.c > +++ b/sys/netinet/tcp_input.c > @@ -921,6 +921,16 @@ findpcb: > goto dropwithreset; > } > INP_WLOCK_ASSERT(inp); > + /* > + * While waiting for inp lock during the lookup, another thread > + * can have droppedt the inpcb, in which case we need to loop back > + * and try to find a new inpcb to deliver to. > + */ > + if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > + } > if ((inp->inp_flowtype == M_HASHTYPE_NONE) && > (M_HASHTYPE_GET(m) != M_HASHTYPE_NONE) && > ((inp->inp_socket == NULL) || > @@ -981,6 +991,10 @@ relocked: > if (in_pcbrele_wlocked(inp)) { > inp = NULL; > goto findpcb; > + } else if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > } > } else > ti_locked = TI_RLOCKED; > @@ -1040,6 +1054,10 @@ relocked: > if (in_pcbrele_wlocked(inp)) { > inp = NULL; > goto findpcb; > + } else if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > } > goto relocked; > } else > > -- > Julien >
On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote:> > Hi, > > On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > > > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the > >> process continues and calls INP_WUNLOCK() here: > >> > >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > > > Look also to sys/netinet/tcp_timewait.c:488 > > > > And check other locks from r160549 > > You are right, and here the a fix proposal for this issue: > > Fix a double-free when an inp transitions to INP_TIMEWAIT state after > having been dropped > https://reviews.freebsd.org/D8211 > > It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED > inpcb should never be proceed further. > > Slawa, as you are the only one to reproduce this issue currently, could > test this patch? (And remove the temporary patch I did provided to you > before). > > I will wait for your tests results before pushing further. > > Thanks! > > diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c > index c72f01f..37f27e0 100644 > --- a/sys/netinet/tcp_input.c > +++ b/sys/netinet/tcp_input.c > @@ -921,6 +921,16 @@ findpcb: > goto dropwithreset; > } > INP_WLOCK_ASSERT(inp); > + /* > + * While waiting for inp lock during the lookup, another thread > + * can have droppedt the inpcb, in which case we need to loop back > + * and try to find a new inpcb to deliver to. > + */ > + if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb;Are you sure about this goto? Can this cause infinite loop by found same inpcb? May be drop packet is more correct?