Hi Gerd, the cause for the segfault is the call of the function state.c:delete_states_by_connection() in ipsec_doi.c:dpd_timeout()
http://wiki.strongswan.org/browser/trunk/src/pluto/ipsec_doi.c#L5615 which deletes the connection c if it has been instantiated http://wiki.strongswan.org/browser/trunk/src/pluto/state.c#L468 Thus the subsequent call of unroute_connection(c) for the cases DPD_ACTION_CLEAR and DPD_ACTION_RESTART in dpd_timeout() can cause a segfault if the memory has already been re-allocated in the meantime: switch (action) { case DPD_ACTION_HOLD: loglog(RC_LOG_SERIOUS, "DPD: Putting connection into %%trap"); break; case DPD_ACTION_CLEAR: loglog(RC_LOG_SERIOUS, "DPD: Clearing connection"); unroute_connection(c); break; case DPD_ACTION_RESTART: loglog(RC_LOG_SERIOUS, "DPD: Restarting connection"); unroute_connection(c); initiate_connection(c->name, NULL_FD); break; default: loglog(RC_LOG_SERIOUS, "DPD: unknown action"); } A simple workaround in order to avoid segfaults would be to not call unroute_connection(c) if c->kind == CK_INSTANCE and to cache c->name. Unfortunately DPD_ACTION_RESTART would not succeed by using the connection template designated by c->name if right=%any or if the IP address of the peer has changed in the meantime in the case of rightallowany=yes. Thus the proper way would be to avoid deleting the connection instance in the DPD timeout case so that the latest IP address would still be available. Best regards Andreas Gerd v. Egidy wrote: > Hi, > > one of our customers experienced repeated pluto segfaults. We ruled out > hardware issues. I already found the problem in may last year and wrote a > description of what I had found out: > > https://lists.strongswan.org/pipermail/users/2008-May/002446.html > > The segfault always happens when a dead peer is detected but not all dead > peers lead to segfaults. > > The problem is still bugging us so I created a testcase for the UML-based > test > framework. It is attached as dynamic-responder.dpd.tar.gz. It is not exactly > what the customer is doing but the easiest way I came up with to trigger it. > > It is a use-after-free bug in ipsec_doi:dpd_timeout(). It only sometimes > segfaults when the memory is allocated in a special way. I attached a small > patch which overwrites the connection-structure directly before it is freed. > With this patch you can always trigger the segfault. > > It would be nice if one of the strongswan developers with deeper insight into > the code could take a look at this. > > Kind regards, > > Gerd > ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
