netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).