Re: [Security] Fwd: Oops (bad memory deref) in slab_alloc() due tofilp_cachep holding incorrect values

[Robert ÅwiÄcki]

>> Given that it doesn't seem to appear in 2.6.39-rc4, and judging by the
>> names of functions involved, this change looks suspiciously related to
>> this oops (even if it just made the keyctl problem visible)
>> http://git.itanic.dy.fi/?p=linux-stable;a=commitdiff;h=47a150edc2ae734c0f4bf50aa19499e23b9a46f8
>>
>> >> #include <sys/stat.h>
>> >> #include <sys/wait.h>
>> >> #include <unistd.h>
>> >> #include <sys/syscall.h>
>> >> #include <linux/keyctl.h>
>> >> #include <linux/sched.h>
>> >>
>> >> int TH1(void *dummy) {
>> >> Â Â Â Âsyscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
>
> Thanks!
>
> Fooi, it looks like all users of cred_alloc_blank() may need to be
> audited wrt commit 47a150edc2ae734c0f4bf50aa19499e23b9a46f8.
>
> Does this fix the bug you're seeing?

Yup, the kernel survives both the testcase and a short syscall fuzzing
session. Thanks.

> From: Serge E. Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> Date: Wed, 25 May 2011 15:41:23 +0100
> Subject: [PATCH 1/1] Set cred->user_ns in key_replace_session_keyring
>
> Since this cred was not created with copy_creds(), it needs to get
> initialized.
>
> Signed-off-by: Serge E. Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> ---
> Â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

-- 
Robert ÅwiÄcki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/