From: Paul Moore <paul@paul-moore.com>
To: Nikolay Aleksandrov <nikolay@redhat.com>,
Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org, Dave Jones <davej@redhat.com>,
Fan Du <fan.du@windriver.com>,
"David S. Miller" <davem@davemloft.net>,
linux-security-module@vger.kernel.org
Subject: Re: Possible fix
Date: Fri, 28 Feb 2014 17:10:47 -0500 [thread overview]
Message-ID: <8608950.OLpq4oFFJB@sifl> (raw)
In-Reply-To: <5310607F.7030401@redhat.com>
On Friday, February 28, 2014 11:10:07 AM Nikolay Aleksandrov wrote:
> On 02/28/2014 08:23 AM, Steffen Klassert wrote:
> > On Thu, Feb 27, 2014 at 05:17:37PM +0100, Nikolay Aleksandrov wrote:
> >> Hi,
> >> I'm not familiar with the code but happened to see the bug, could you
> >> try the following patch, I believe it should fix the issue.
> >>
> >> Thanks,
> >>
> >> Nik
> >>
> >> [PATCH net] net: af_key: fix sleeping under rcu
> >>
> >> There's a kmalloc with GFP_KERNEL in a helper
> >> (pfkey_sadb2xfrm_user_sec_ctx) used in pfkey_compile_policy which is
> >> called under rcu_read_lock. Adjust pfkey_sadb2xfrm_user_sec_ctx to have
> >> a gfp argument and adjust the users.
> >
> > Looking at the git history, it seems that this bug is about nine
> > years old. I guess noone is actually using this.
Most (all?) of the labeled IPsec users use the netlink interface and not pfkey
so it isn't surprising that this has gone unnoticed for some time.
> >> diff --git a/net/key/af_key.c b/net/key/af_key.c
> >> index 1a04c1329362..1526023f99ed 100644
> >> --- a/net/key/af_key.c
> >> +++ b/net/key/af_key.c
> >> @@ -3239,7 +3240,7 @@ static struct xfrm_policy
> >> *pfkey_compile_policy(struct sock *sk, int opt,>>
> >> }
> >> if ((*dir = verify_sec_ctx_len(p)))
> >>
> >> goto out;
> >>
> >> - uctx = pfkey_sadb2xfrm_user_sec_ctx(sec_ctx);
> >> + uctx = pfkey_sadb2xfrm_user_sec_ctx(sec_ctx, GFP_ATOMIC);
> >>
> >> *dir = security_xfrm_policy_alloc(&xp->security, uctx);
> >
> > This would fix the allocation done in pfkey_sadb2xfrm_user_sec_ctx().
> > But security_xfrm_policy_alloc() might call selinux_xfrm_alloc_user()
> > which does a GFP_KERNEL allocation too. So I guess we also need to fix
> > selinux.
Yes, exactly.
> Right, I just saw that but fixing it at first glance doesn't seem so
> trivial as we can't pass another argument from compile_policy without
> changing xfrm_policy_alloc_security's prototype in struct
> security_operations which AFAICT is doable with some adjustments, but not
> sure if it's the right thing to do. Changing GFP_KERNEL to GFP_ATOMIC in
> selinux_xfrm_alloc_user is also a possibility, but there're a many places
> which use that and can sleep.
I would recommend adding a gfp_t argument to security_xfrm_policy_alloc() and
passing GFP_ATOMIC in pfkey_compile_policy().
> I would extend this patch, but currently don't have the time to search for
> a nice solution. I can look more into it next week, or if you'd like to
> take care of it, I wouldn't mind :-)
It has been this way for a while so I think another day or two isn't going to
cause any major harm. If you are going to put a patch together that's great,
CC me and I'll review/ACK it, but if you don't want to bother let me know and
I'll work on a patch.
Thanks,
-Paul
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2014-02-28 22:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 15:19 kmalloc with locks held in xfrm Dave Jones
2014-02-27 16:17 ` Possible fix Nikolay Aleksandrov
2014-02-27 16:24 ` Nikolay Aleksandrov
2014-02-27 17:05 ` Nikolay Aleksandrov
2014-02-28 7:23 ` Steffen Klassert
2014-02-28 10:10 ` Nikolay Aleksandrov
2014-02-28 22:10 ` Paul Moore [this message]
2014-03-02 16:26 ` Nikolay Aleksandrov
2014-03-05 12:20 ` Steffen Klassert
2014-03-07 3:04 ` Paul Moore
2014-03-07 11:23 ` Steffen Klassert
2014-03-07 15:50 ` Paul Moore
2014-03-04 12:26 ` [PATCH 0/2] af_key: fixes for sleeping while atomic Nikolay Aleksandrov
2014-03-04 12:26 ` [PATCH 1/2] net: af_key: fix sleeping under rcu Nikolay Aleksandrov
2014-03-04 12:46 ` David Laight
2014-03-04 21:40 ` David Miller
2014-03-04 12:26 ` [PATCH 2/2] selinux: add gfp argument to security_xfrm_policy_alloc and fix callers Nikolay Aleksandrov
2014-03-07 3:22 ` Paul Moore
2014-03-07 10:52 ` Nikolay Aleksandrov
2014-03-05 12:07 ` [PATCH 0/2] af_key: fixes for sleeping while atomic Steffen Klassert
2014-03-05 22:21 ` Paul Moore
2014-03-07 11:44 ` [PATCHv2 " Nikolay Aleksandrov
2014-03-07 11:44 ` [PATCHv2 1/2] net: af_key: fix sleeping under rcu Nikolay Aleksandrov
2014-03-07 11:44 ` [PATCHv2 2/2] selinux: add gfp argument to security_xfrm_policy_alloc and fix callers Nikolay Aleksandrov
2014-03-07 22:27 ` Paul Moore
2014-03-10 12:52 ` Steffen Klassert
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=8608950.OLpq4oFFJB@sifl \
--to=paul@paul-moore.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=fan.du@windriver.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@redhat.com \
--cc=steffen.klassert@secunet.com \
/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).