From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [XFRM]: Fix leak of expired xfrm_states
Date: Mon, 26 Nov 2007 17:52:15 +0100 [thread overview]
Message-ID: <474AF9BF.2050603@trash.net> (raw)
In-Reply-To: <20071126162223.GA29293@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Herbert Xu wrote:
> On Mon, Nov 26, 2007 at 04:56:01PM +0100, Patrick McHardy wrote:
>> That should work as long as we keep the del_timer_sync to avoid
>> a use-after-free. It seems a bit fragile though.
>
> Well we're relying on the del_timer_sync already to avoid the
> ref count on the timer. Otherwise if the admin deletes the
> SA while the timer is running it'll go up in smoke too.
>
> If you look in the history you'll find that the same patch
> that removed the ref count on the timer introduced the call
> to del_timer_sync :)
OK, here's a patch to use xfrm_state_put in __xfrm_state_delete().
I've checked the other callers and it should be fine. lock ordering
between x->lock and xfrm_state_gc_lock also doesn't seem to be an
issue.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 975 bytes --]
commit ba63b1baf5d8a63f3bb3097a7201de75c1b77e2d
Author: Patrick McHardy <kaber@trash.net>
Date: Mon Nov 26 16:00:50 2007 +0100
[XFRM]: Fix leak of expired xfrm_states
The xfrm_timer calls __xfrm_state_delete, which drops the final reference
manually without triggering destruction of the state. Change it to use
xfrm_state_put to add the state to the gc list when we're dropping the
last reference. The timer function may still continue to use the state
safely since the final destruction does a del_timer_sync().
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 224b44e..cf43c49 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -552,7 +552,7 @@ int __xfrm_state_delete(struct xfrm_state *x)
* The xfrm_state_alloc call gives a reference, and that
* is what we are dropping here.
*/
- __xfrm_state_put(x);
+ xfrm_state_put(x);
err = 0;
}
next prev parent reply other threads:[~2007-11-26 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-26 15:05 [XFRM]: Fix leak of expired xfrm_states Patrick McHardy
2007-11-26 15:46 ` Herbert Xu
2007-11-26 15:51 ` Patrick McHardy
2007-11-26 15:54 ` Herbert Xu
2007-11-26 15:56 ` Patrick McHardy
2007-11-26 16:22 ` Herbert Xu
2007-11-26 16:52 ` Patrick McHardy [this message]
2007-11-27 3:11 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474AF9BF.2050603@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).