Thread (11 messages) 11 messages, 3 authors, 2014-02-27

Re: [PATCH 5/5] xfrm: Fix unlink race when policies are deleted.

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: 2014-02-27 06:53:56

On Thu, Feb 27, 2014 at 02:30:15PM +0800, Herbert Xu wrote:
On Thu, Feb 27, 2014 at 02:27:12PM +0800, Herbert Xu wrote:
quoted
On Thu, Feb 27, 2014 at 07:16:39AM +0100, Steffen Klassert wrote:
quoted
When a policy is unlinked from the lists in thread context,
the xfrm timer can fire before we can mark this policy as dead.
So reinitialize the bydst hlist, then hlist_unhashed() will
notice that this policy is not linked and will avoid a
doulble unlink of that policy.

Reported-by: Xianpeng Zhao <redacted>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
If this race condition is real then I don't see how this fix
can be correct since there aren't any barriers between the check
and the unlink.
Looking at the code it seems that we've already taken the policy
lock so how can this race occur?
We take the policy lock in xfrm_policy_delete() before we
unlink the policy. But we release it before we mark the
policy as dead with xfrm_policy_kill(). If the timer fires
in the meantime it can be unlinked from the timer first
and then again from xfrm_policy_delete().

This issue was originally reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=70471
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help