Since active task's destruction might result in adopting tasks from a
rekeyed ike sa it seems better to first destroy the active task list and
then destroy all queued tasks. This way adoption is possible at all,
while otherwise the queued task list would be empty.
Also fixes a TOCTOU issue regarding the use of entry_t.pending.
The deadlock was caused because the rwlock was being locked while
waiting for an IKE_SA. Triggering the deadlock was a bit tricky, here
is the description by Thomas Egerer (the reporter of this issue):
"
The deadlock occurs when the following happens (in the given order):
a) an IKE_SA is built and a thread is processing the IKE_AUTH request,
which can take a bit longer when a smartcard is involved. This
causes the ike_sa_manager to lock a particular IKE_SA exclusively.
b) an acquire is triggered which causes the rwlock in the trap_manager
to be read-locked, the subsequent call to
ike_sa_manager->checkout_by_config has to wait until a) unlocks
it's ike_sa.
c) a child_cfg contained in the peer_cfg belonging to the ike_sa
a) has locked is routed causes the child_configs contained
in the peer config to be locked by c) while the actual routing
code within trap_manager tries to writelock it's rwlock.
That's about it. As soon as a) finishes authentication of the peer
and tries to find a matching child sa it will try to lock the child
configs of the peer config which is not possible since it has been
locked by c).
Thread | Resource locked | Resource desired
-------+--------------------------------+--------------------------------
(a) | ike_sa in ike_sa_manager | child_cfgs of peer_cfg
| |
(b) | rwlock in trap-manager (read) | ike_sa in ike_sa_manager
| |
(c) | child_cfgs of peer_cfg | rwlock in trap-manager (write)
"
With this patch thread (b) now does not hold the lock while waiting for
the IKE_SA. Thus (c) can get the write lock, and (a) can subsequently
lock the mutex in the peer_cfg which then finally allows (b) to checkout
the IKE_SA.
During the update of a CHILD_SA (e.g. caused by MOBIKE) the old policy
is first uninstalled and then the new one is installed. In the short
time in between, where no policy is available in the kernel, unencrypted
packets could have been transmitted.
This allows to unroute a connection while the same connection is
currently established. In this case both CHILD_SAs share the same
reqid but the installed policies have different priorities.
Martin Willi