Since this cred was not created with copy_creds(), it needs to get
initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
can lead to a NULL deref. Thanks to Robert for finding this.
Signed-off-by: Serge E. Hallyn <[email protected]>
Reported-by: Robert Święcki <[email protected]>
Cc: David Howells <[email protected]>
---
security/keys/process_keys.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 6c0480d..92a3a5d 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -847,6 +847,7 @@ void key_replace_session_keyring(void)
new-> sgid = old-> sgid;
new->fsgid = old->fsgid;
new->user = get_uid(old->user);
+ new->user_ns = new->user->user_ns;
new->group_info = get_group_info(old->group_info);
new->securebits = old->securebits;
--
1.7.0.4
Shouldn't this also be "Cc: stable" for 2.6.39?
Bug introduced by commit 47a150edc2a, no?
Linus
On Thu, May 26, 2011 at 1:25 PM, Serge E. Hallyn <[email protected]> wrote:
> Since this cred was not created with copy_creds(), it needs to get
> initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
> can lead to a NULL deref. Thanks to Robert for finding this.
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
> Reported-by: Robert Święcki <[email protected]>
> Cc: David Howells <[email protected]>
> ---
> security/keys/process_keys.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> index 6c0480d..92a3a5d 100644
> --- a/security/keys/process_keys.c
> +++ b/security/keys/process_keys.c
> @@ -847,6 +847,7 @@ void key_replace_session_keyring(void)
> new-> sgid = old-> sgid;
> new->fsgid = old->fsgid;
> new->user = get_uid(old->user);
> + new->user_ns = new->user->user_ns;
> new->group_info = get_group_info(old->group_info);
>
> new->securebits = old->securebits;
> --
> 1.7.0.4
>
>
Quoting Linus Torvalds ([email protected]):
> Shouldn't this also be "Cc: stable" for 2.6.39?
>
> Bug introduced by commit 47a150edc2a, no?
Yup, introduced there.
Stable/whoever, should I re-send this patch separately, or does this suffice?
thanks,
-serge
> Linus
>
> On Thu, May 26, 2011 at 1:25 PM, Serge E. Hallyn <[email protected]> wrote:
> > Since this cred was not created with copy_creds(), it needs to get
> > initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
> > can lead to a NULL deref. Thanks to Robert for finding this.
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > Reported-by: Robert Święcki <[email protected]>
> > Cc: David Howells <[email protected]>
> > ---
> > security/keys/process_keys.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> > index 6c0480d..92a3a5d 100644
> > --- a/security/keys/process_keys.c
> > +++ b/security/keys/process_keys.c
> > @@ -847,6 +847,7 @@ void key_replace_session_keyring(void)
> > new-> sgid = old-> sgid;
> > new->fsgid = old->fsgid;
> > new->user = get_uid(old->user);
> > + new->user_ns = new->user->user_ns;
> > new->group_info = get_group_info(old->group_info);
> >
> > new->securebits = old->securebits;
> > --
> > 1.7.0.4
> >
> >
On Thu, May 26, 2011 at 1:38 PM, Serge E. Hallyn <[email protected]> wrote:
>
> Stable/whoever, should I re-send this patch separately, or does this suffice?
I'll add the Cc and update the description to point to the commit it
was introduced in, and it will all be fine. Then the stable team will
get it automatically when I push out.
Linus
Quoting Linus Torvalds ([email protected]):
> On Thu, May 26, 2011 at 1:38 PM, Serge E. Hallyn <[email protected]> wrote:
> >
> > Stable/whoever, should I re-send this patch separately, or does this suffice?
>
> I'll add the Cc and update the description to point to the commit it
> was introduced in, and it will all be fine. Then the stable team will
> get it automatically when I push out.
>
> Linus
Thanks very much. (I see now)
-serge