Eric Lee / smarc-fsl-linux-kernel

31 Oct, 2011

1 commit

  • 9984de1a5   kernel: Map most files to use export.h instead of module.h ... Browse Code »

    The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else. Revector them
    onto the isolated export header for faster compile times.

    Nothing to see here but a whole lot of instances of:

    -#include
    +#include

    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

25 Oct, 2011

1 commit

  • 36b8d186e   Merge branch 'next' of git://selinuxproject.org/~jmorris/linux-security ... Browse Code »

    * 'next' of git://selinuxproject.org/~jmorris/linux-security: (95 commits)
    TOMOYO: Fix incomplete read after seek.
    Smack: allow to access /smack/access as normal user
    TOMOYO: Fix unused kernel config option.
    Smack: fix: invalid length set for the result of /smack/access
    Smack: compilation fix
    Smack: fix for /smack/access output, use string instead of byte
    Smack: domain transition protections (v3)
    Smack: Provide information for UDS getsockopt(SO_PEERCRED)
    Smack: Clean up comments
    Smack: Repair processing of fcntl
    Smack: Rule list lookup performance
    Smack: check permissions from user space (v2)
    TOMOYO: Fix quota and garbage collector.
    TOMOYO: Remove redundant tasklist_lock.
    TOMOYO: Fix domain transition failure warning.
    TOMOYO: Remove tomoyo_policy_memory_lock spinlock.
    TOMOYO: Simplify garbage collector.
    TOMOYO: Fix make namespacecheck warnings.
    target: check hex2bin result
    encrypted-keys: check hex2bin result
    ...

    Linus Torvalds
     

23 Aug, 2011

2 commits

  • 8ad346c62   CRED: fix build error due to 'tgcred' undeclared ... Browse Code »

    This patch adds CONFIG_KEYS guard for tgcred to fix below build error
    if CONFIG_KEYS is not configured.

    CC kernel/cred.o
    kernel/cred.c: In function 'prepare_kernel_cred':
    kernel/cred.c:657: error: 'tgcred' undeclared (first use in this function)
    kernel/cred.c:657: error: (Each undeclared identifier is reported only once
    kernel/cred.c:657: error: for each function it appears in.)
    make[1]: *** [kernel/cred.o] Error 1
    make: *** [kernel] Error 2

    Signed-off-by: Axel Lin
    Acked-by: David Howells
    Signed-off-by: James Morris

    Axel Lin
     
  • 012146d07   CRED: Fix prepare_kernel_cred() to provide a new thread_group_cred struct ... Browse Code »

    Fix prepare_kernel_cred() to provide a new, separate thread_group_cred struct
    otherwise when using request_key() ____call_usermodehelper() calls
    umh_keys_init() with the new creds pointing to init_tgcred, which
    umh_keys_init() then blithely alters.

    The problem can be demonstrated by:

    # keyctl request2 user a debug:a @s
    249681132
    # grep req /proc/keys
    079906a5 I--Q-- 1 perm 1f3f0000 0 0 keyring _req.249681132: 1/4
    38ef1626 IR---- 1 expd 0b010000 0 0 .request_ key:ee1d4ec pid:4371 ci:1

    The keyring _req.XXXX should have gone away, but something (init_tgcred) is
    pinning it.

    That key actually requested can then be removed and a new one created:

    # keyctl unlink 249681132
    1 links removed
    [root@andromeda ~]# grep req /proc/keys
    116cecac IR---- 1 expd 0b010000 0 0 .request_ key:eeb4911 pid:4379 ci:1
    36d1cbf8 I--Q-- 1 perm 1f3f0000 0 0 keyring _req.250300689: 1/4

    which causes the old _req keyring to go away and a new one to take its place.

    This is a consequence of the changes in:

    commit 879669961b11e7f40b518784863a259f735a72bf
    Author: David Howells
    Date: Fri Jun 17 11:25:59 2011 +0100
    KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring

    and:

    commit 17f60a7da150fdd0cfb9756f86a262daa72c835f
    Author: Eric Paris
    Date: Fri Apr 1 17:07:50 2011 -0400
    capabilites: allow the application of capability limits to usermode helpers

    After this patch is applied, the _req keyring and the .request_key key are
    cleaned up.

    Signed-off-by: David Howells
    cc: Eric Paris
    Signed-off-by: James Morris

    David Howells
     

12 Aug, 2011

1 commit

  • 72fa59970   move RLIMIT_NPROC check from set_user() to do_execve_common() ... Browse Code »

    The patch http://lkml.org/lkml/2003/7/13/226 introduced an RLIMIT_NPROC
    check in set_user() to check for NPROC exceeding via setuid() and
    similar functions.

    Before the check there was a possibility to greatly exceed the allowed
    number of processes by an unprivileged user if the program relied on
    rlimit only. But the check created new security threat: many poorly
    written programs simply don't check setuid() return code and believe it
    cannot fail if executed with root privileges. So, the check is removed
    in this patch because of too often privilege escalations related to
    buggy programs.

    The NPROC can still be enforced in the common code flow of daemons
    spawning user processes. Most of daemons do fork()+setuid()+execve().
    The check introduced in execve() (1) enforces the same limit as in
    setuid() and (2) doesn't create similar security issues.

    Neil Brown suggested to track what specific process has exceeded the
    limit by setting PF_NPROC_EXCEEDED process flag. With the change only
    this process would fail on execve(), and other processes' execve()
    behaviour is not changed.

    Solar Designer suggested to re-check whether NPROC limit is still
    exceeded at the moment of execve(). If the process was sleeping for
    days between set*uid() and execve(), and the NPROC counter step down
    under the limit, the defered execve() failure because NPROC limit was
    exceeded days ago would be unexpected. If the limit is not exceeded
    anymore, we clear the flag on successful calls to execve() and fork().

    The flag is also cleared on successful calls to set_user() as the limit
    was exceeded for the previous user, not the current one.

    Similar check was introduced in -ow patches (without the process flag).

    v3 - clear PF_NPROC_EXCEEDED on successful calls to set_user().

    Reviewed-by: James Morris
    Signed-off-by: Vasiliy Kulikov
    Acked-by: NeilBrown
    Signed-off-by: Linus Torvalds

    Vasiliy Kulikov
     

28 May, 2011

1 commit

20 May, 2011

1 commit

19 May, 2011

1 commit

14 May, 2011

1 commit

  • 47a150edc   Cache user_ns in struct cred ... Browse Code »

    If !CONFIG_USERNS, have current_user_ns() defined to (&init_user_ns).

    Get rid of _current_user_ns. This requires nsown_capable() to be
    defined in capability.c rather than as static inline in capability.h,
    so do that.

    Request_key needs init_user_ns defined at current_user_ns if
    !CONFIG_USERNS, so forward-declare that in cred.h if !CONFIG_USERNS
    at current_user_ns() define.

    Compile-tested with and without CONFIG_USERNS.

    Signed-off-by: Serge E. Hallyn
    [ This makes a huge performance difference for acl_permission_check(),
    up to 30%. And that is one of the hottest kernel functions for loads
    that are pathname-lookup heavy. ]
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

04 Apr, 2011

1 commit

24 Mar, 2011

1 commit

  • 3486740a4   userns: security: make capabilities relative to the user namespace ... Browse Code »

    - Introduce ns_capable to test for a capability in a non-default
    user namespace.
    - Teach cap_capable to handle capabilities in a non-default
    user namespace.

    The motivation is to get to the unprivileged creation of new
    namespaces. It looks like this gets us 90% of the way there, with
    only potential uid confusion issues left.

    I still need to handle getting all caps after creation but otherwise I
    think I have a good starter patch that achieves all of your goals.

    Changelog:
    11/05/2010: [serge] add apparmor
    12/14/2010: [serge] fix capabilities to created user namespaces
    Without this, if user serge creates a user_ns, he won't have
    capabilities to the user_ns he created. THis is because we
    were first checking whether his effective caps had the caps
    he needed and returning -EPERM if not, and THEN checking whether
    he was the creator. Reverse those checks.
    12/16/2010: [serge] security_real_capable needs ns argument in !security case
    01/11/2011: [serge] add task_ns_capable helper
    01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
    02/16/2011: [serge] fix a logic bug: the root user is always creator of
    init_user_ns, but should not always have capabilities to
    it! Fix the check in cap_capable().
    02/21/2011: Add the required user_ns parameter to security_capable,
    fixing a compile failure.
    02/23/2011: Convert some macros to functions as per akpm comments. Some
    couldn't be converted because we can't easily forward-declare
    them (they are inline if !SECURITY, extern if SECURITY). Add
    a current_user_ns function so we can use it in capability.h
    without #including cred.h. Move all forward declarations
    together to the top of the #ifdef __KERNEL__ section, and use
    kernel-doc format.
    02/23/2011: Per dhowells, clean up comment in cap_capable().
    02/23/2011: Per akpm, remove unreachable 'return -EPERM' in cap_capable.

    (Original written and signed off by Eric; latest, modified version
    acked by him)

    [akpm@linux-foundation.org: fix build]
    [akpm@linux-foundation.org: export current_user_ns() for ecryptfs]
    [serge.hallyn@canonical.com: remove unneeded extra argument in selinux's task_has_capability]
    Signed-off-by: Eric W. Biederman
    Signed-off-by: Serge E. Hallyn
    Acked-by: "Eric W. Biederman"
    Acked-by: Daniel Lezcano
    Acked-by: David Howells
    Cc: James Morris
    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

16 Feb, 2011

1 commit

08 Feb, 2011

2 commits

  • fb2b2a1d3   CRED: Fix memory and refcount leaks upon security_prepare_creds() failure ... Browse Code »

    In prepare_kernel_cred() since 2.6.29, put_cred(new) is called without
    assigning new->usage when security_prepare_creds() returned an error. As a
    result, memory for new and refcount for new->{user,group_info,tgcred} are
    leaked because put_cred(new) won't call __put_cred() unless old->usage == 1.

    Fix these leaks by assigning new->usage (and new->subscribers which was added
    in 2.6.32) before calling security_prepare_creds().

    Signed-off-by: Tetsuo Handa
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Tetsuo Handa
     
  • 2edeaa34a   CRED: Fix BUG() upon security_cred_alloc_blank() failure ... Browse Code »

    In cred_alloc_blank() since 2.6.32, abort_creds(new) is called with
    new->security == NULL and new->magic == 0 when security_cred_alloc_blank()
    returns an error. As a result, BUG() will be triggered if SELinux is enabled
    or CONFIG_DEBUG_CREDENTIALS=y.

    If CONFIG_DEBUG_CREDENTIALS=y, BUG() is called from __invalid_creds() because
    cred->magic == 0. Failing that, BUG() is called from selinux_cred_free()
    because selinux_cred_free() is not expecting cred->security == NULL. This does
    not affect smack_cred_free(), tomoyo_cred_free() or apparmor_cred_free().

    Fix these bugs by

    (1) Set new->magic before calling security_cred_alloc_blank().

    (2) Handle null cred->security in creds_are_invalid() and selinux_cred_free().

    Signed-off-by: Tetsuo Handa
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Tetsuo Handa
     

27 Jan, 2011

1 commit

28 Oct, 2010

1 commit

  • 9b1bf12d5   signals: move cred_guard_mutex from task_struct to signal_struct ... Browse Code »

    Oleg Nesterov pointed out we have to prevent multiple-threads-inside-exec
    itself and we can reuse ->cred_guard_mutex for it. Yes, concurrent
    execve() has no worth.

    Let's move ->cred_guard_mutex from task_struct to signal_struct. It
    naturally prevent multiple-threads-inside-exec.

    Signed-off-by: KOSAKI Motohiro
    Reviewed-by: Oleg Nesterov
    Acked-by: Roland McGrath
    Acked-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KOSAKI Motohiro
     

13 Aug, 2010

1 commit

30 Jul, 2010

1 commit

  • de09a9771   CRED: Fix get_task_cred() and task_state() to not resurrect dead credentials ... Browse Code »

    It's possible for get_task_cred() as it currently stands to 'corrupt' a set of
    credentials by incrementing their usage count after their replacement by the
    task being accessed.

    What happens is that get_task_cred() can race with commit_creds():

    TASK_1 TASK_2 RCU_CLEANER
    -->get_task_cred(TASK_2)
    rcu_read_lock()
    __cred = __task_cred(TASK_2)
    -->commit_creds()
    old_cred = TASK_2->real_cred
    TASK_2->real_cred = ...
    put_cred(old_cred)
    call_rcu(old_cred)
    [__cred->usage == 0]
    get_cred(__cred)
    [__cred->usage == 1]
    rcu_read_unlock()
    -->put_cred_rcu()
    [__cred->usage == 1]
    panic()

    However, since a tasks credentials are generally not changed very often, we can
    reasonably make use of a loop involving reading the creds pointer and using
    atomic_inc_not_zero() to attempt to increment it if it hasn't already hit zero.

    If successful, we can safely return the credentials in the knowledge that, even
    if the task we're accessing has released them, they haven't gone to the RCU
    cleanup code.

    We then change task_state() in procfs to use get_task_cred() rather than
    calling get_cred() on the result of __task_cred(), as that suffers from the
    same problem.

    Without this change, a BUG_ON in __put_cred() or in put_cred_rcu() can be
    tripped when it is noticed that the usage count is not zero as it ought to be,
    for example:

    kernel BUG at kernel/cred.c:168!
    invalid opcode: 0000 [#1] SMP
    last sysfs file: /sys/kernel/mm/ksm/run
    CPU 0
    Pid: 2436, comm: master Not tainted 2.6.33.3-85.fc13.x86_64 #1 0HR330/OptiPlex
    745
    RIP: 0010:[] [] __put_cred+0xc/0x45
    RSP: 0018:ffff88019e7e9eb8 EFLAGS: 00010202
    RAX: 0000000000000001 RBX: ffff880161514480 RCX: 00000000ffffffff
    RDX: 00000000ffffffff RSI: ffff880140c690c0 RDI: ffff880140c690c0
    RBP: ffff88019e7e9eb8 R08: 00000000000000d0 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000040 R12: ffff880140c690c0
    R13: ffff88019e77aea0 R14: 00007fff336b0a5c R15: 0000000000000001
    FS: 00007f12f50d97c0(0000) GS:ffff880007400000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8f461bc000 CR3: 00000001b26ce000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process master (pid: 2436, threadinfo ffff88019e7e8000, task ffff88019e77aea0)
    Stack:
    ffff88019e7e9ec8 ffffffff810698cd ffff88019e7e9ef8 ffffffff81069b45
    ffff880161514180 ffff880161514480 ffff880161514180 0000000000000000
    ffff88019e7e9f28 ffffffff8106aace 0000000000000001 0000000000000246
    Call Trace:
    [] put_cred+0x13/0x15
    [] commit_creds+0x16b/0x175
    [] set_current_groups+0x47/0x4e
    [] sys_setgroups+0xf6/0x105
    [] system_call_fastpath+0x16/0x1b
    Code: 48 8d 71 ff e8 7e 4e 15 00 85 c0 78 0b 8b 75 ec 48 89 df e8 ef 4a 15 00
    48 83 c4 18 5b c9 c3 55 8b 07 8b 07 48 89 e5 85 c0 74 04 0b eb fe 65 48 8b
    04 25 00 cc 00 00 48 3b b8 58 04 00 00 75
    RIP [] __put_cred+0xc/0x45
    RSP
    ---[ end trace df391256a100ebdd ]---

    Signed-off-by: David Howells
    Acked-by: Jiri Olsa
    Signed-off-by: Linus Torvalds

    David Howells
     

28 May, 2010

1 commit

  • c70a626d3   umh: creds: kill subprocess_info->cred logic ... Browse Code »

    Now that nobody ever changes subprocess_info->cred we can kill this member
    and related code. ____call_usermodehelper() always runs in the context of
    freshly forked kernel thread, it has the proper ->cred copied from its
    parent kthread, keventd.

    Signed-off-by: Oleg Nesterov
    Acked-by: Neil Horman
    Acked-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

20 May, 2010

1 commit

  • 96b5b7f4f   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorri… ... Browse Code »

    …s/security-testing-2.6

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (61 commits)
    KEYS: Return more accurate error codes
    LSM: Add __init to fixup function.
    TOMOYO: Add pathname grouping support.
    ima: remove ACPI dependency
    TPM: ACPI/PNP dependency removal
    security/selinux/ss: Use kstrdup
    TOMOYO: Use stack memory for pending entry.
    Revert "ima: remove ACPI dependency"
    Revert "TPM: ACPI/PNP dependency removal"
    KEYS: Do preallocation for __key_link()
    TOMOYO: Use mutex_lock_interruptible.
    KEYS: Better handling of errors from construct_alloc_key()
    KEYS: keyring_serialise_link_sem is only needed for keyring->keyring links
    TOMOYO: Use GFP_NOFS rather than GFP_KERNEL.
    ima: remove ACPI dependency
    TPM: ACPI/PNP dependency removal
    selinux: generalize disabling of execmem for plt-in-heap archs
    LSM Audit: rename LSM_AUDIT_NO_AUDIT to LSM_AUDIT_DATA_NONE
    CRED: Holding a spinlock does not imply the holding of RCU read lock
    SMACK: Don't #include Ext2 headers
    ...

    Linus Torvalds
     

07 May, 2010

1 commit

06 May, 2010

1 commit

22 Apr, 2010

1 commit

  • e134d200d   CRED: Fix a race in creds_are_invalid() in credentials debugging ... Browse Code »

    creds_are_invalid() reads both cred->usage and cred->subscribers and then
    compares them to make sure the number of processes subscribed to a cred struct
    never exceeds the refcount of that cred struct.

    The problem is that this can cause a race with both copy_creds() and
    exit_creds() as the two counters, whilst they are of atomic_t type, are only
    atomic with respect to themselves, and not atomic with respect to each other.

    This means that if creds_are_invalid() can read the values on one CPU whilst
    they're being modified on another CPU, and so can observe an evolving state in
    which the subscribers count now is greater than the usage count a moment
    before.

    Switching the order in which the counts are read cannot help, so the thing to
    do is to remove that particular check.

    I had considered rechecking the values to see if they're in flux if the test
    fails, but I can't guarantee they won't appear the same, even if they've
    changed several times in the meantime.

    Note that this can only happen if CONFIG_DEBUG_CREDENTIALS is enabled.

    The problem is only likely to occur with multithreaded programs, and can be
    tested by the tst-eintr1 program from glibc's "make check". The symptoms look
    like:

    CRED: Invalid credentials
    CRED: At include/linux/cred.h:240
    CRED: Specified credentials: ffff88003dda5878 [real][eff]
    CRED: ->magic=43736564, put_addr=(null)
    CRED: ->usage=766, subscr=766
    CRED: ->*uid = { 0,0,0,0 }
    CRED: ->*gid = { 0,0,0,0 }
    CRED: ->security is ffff88003d72f538
    CRED: ->security {359, 359}
    ------------[ cut here ]------------
    kernel BUG at kernel/cred.c:850!
    ...
    RIP: 0010:[] [] __invalid_creds+0x4e/0x52
    ...
    Call Trace:
    [] copy_creds+0x6b/0x23f

    Note the ->usage=766 and subscr=766. The values appear the same because
    they've been re-read since the check was made.

    Reported-by: Roland McGrath
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

21 Apr, 2010

1 commit

  • eff30363c   CRED: Fix double free in prepare_usermodehelper_creds() error handling ... Browse Code »

    Patch 570b8fb505896e007fd3bb07573ba6640e51851d:

    Author: Mathieu Desnoyers
    Date: Tue Mar 30 00:04:00 2010 +0100
    Subject: CRED: Fix memory leak in error handling

    attempts to fix a memory leak in the error handling by making the offending
    return statement into a jump down to the bottom of the function where a
    kfree(tgcred) is inserted.

    This is, however, incorrect, as it does a kfree() after doing put_cred() if
    security_prepare_creds() fails. That will result in a double free if 'error'
    is jumped to as put_cred() will also attempt to free the new tgcred record by
    virtue of it being pointed to by the new cred record.

    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

15 Apr, 2010

1 commit

12 Apr, 2010

1 commit

05 Apr, 2010

1 commit

03 Apr, 2010

1 commit

30 Mar, 2010

2 commits

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     
  • 570b8fb50   CRED: Fix memory leak in error handling ... Browse Code »

    Fix a memory leak on an OOM condition in prepare_usermodehelper_creds().

    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    Mathieu Desnoyers
     

03 Feb, 2010

1 commit

  • b8a1d37c5   kernel/cred.c: use kmem_cache_free ... Browse Code »

    Free memory allocated using kmem_cache_zalloc using kmem_cache_free rather
    than kfree.

    The semantic patch that makes this change is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @@
    expression x,E,c;
    @@

    x = \(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
    ... when != x = E
    when != &x
    ?-kfree(x)
    +kmem_cache_free(c,x)
    //

    Signed-off-by: Julia Lawall
    Acked-by: David Howells
    Cc: James Morris
    Cc: Steve Dickson
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: James Morris

    Julia Lawall
     

24 Sep, 2009

2 commits

  • 764db03fe   creds_are_invalid() needs to be exported for use by modules: ... Browse Code »

    ERROR: "creds_are_invalid" [fs/cachefiles/cachefiles.ko] undefined!

    Signed-off-by: Randy Dunlap
    Cc: David Howells
    Cc: James Morris
    Cc: Serge Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: James Morris

    Randy Dunlap
     
  • 74908a000   include/linux/cred.h: fix build ... Browse Code »

    mips allmodconfig:

    include/linux/cred.h: In function `creds_are_invalid':
    include/linux/cred.h:187: error: `PAGE_SIZE' undeclared (first use in this function)
    include/linux/cred.h:187: error: (Each undeclared identifier is reported only once
    include/linux/cred.h:187: error: for each function it appears in.)

    Fixes

    commit b6dff3ec5e116e3af6f537d4caedcad6b9e5082a
    Author: David Howells
    AuthorDate: Fri Nov 14 10:39:16 2008 +1100
    Commit: James Morris
    CommitDate: Fri Nov 14 10:39:16 2008 +1100

    CRED: Separate task security context from task_struct

    I think.

    It's way too large to be inlined anyway.

    Dunno if this needs an EXPORT_SYMBOL() yet.

    Cc: David Howells
    Cc: James Morris
    Cc: Serge Hallyn
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Signed-off-by: James Morris

    Andrew Morton
     

15 Sep, 2009

1 commit

  • 4a5d6ba19   CRED: Allow put_cred() to cope with a NULL groups list ... Browse Code »

    put_cred() will oops if given a NULL groups list, but that is now possible with
    the existence of cred_alloc_blank(), as used in keyctl_session_to_parent().

    Added in commit:

    commit ee18d64c1f632043a02e6f5ba5e045bb26a5465f
    Author: David Howells
    Date: Wed Sep 2 09:14:21 2009 +0100
    KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]

    Reported-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

02 Sep, 2009

2 commits

  • ee18d64c1   KEYS: Add a keyctl to install a process's session keyring on its parent [try #6] ... Browse Code »

    Add a keyctl to install a process's session keyring onto its parent. This
    replaces the parent's session keyring. Because the COW credential code does
    not permit one process to change another process's credentials directly, the
    change is deferred until userspace next starts executing again. Normally this
    will be after a wait*() syscall.

    To support this, three new security hooks have been provided:
    cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
    the blank security creds and key_session_to_parent() - which asks the LSM if
    the process may replace its parent's session keyring.

    The replacement may only happen if the process has the same ownership details
    as its parent, and the process has LINK permission on the session keyring, and
    the session keyring is owned by the process, and the LSM permits it.

    Note that this requires alteration to each architecture's notify_resume path.
    This has been done for all arches barring blackfin, m68k* and xtensa, all of
    which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
    replacement to be performed at the point the parent process resumes userspace
    execution.

    This allows the userspace AFS pioctl emulation to fully emulate newpag() and
    the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
    alter the parent process's PAG membership. However, since kAFS doesn't use
    PAGs per se, but rather dumps the keys into the session keyring, the session
    keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
    the newpag flag.

    This can be tested with the following program:

    #include
    #include
    #include

    #define KEYCTL_SESSION_TO_PARENT 18

    #define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)

    int main(int argc, char **argv)
    {
    key_serial_t keyring, key;
    long ret;

    keyring = keyctl_join_session_keyring(argv[1]);
    OSERROR(keyring, "keyctl_join_session_keyring");

    key = add_key("user", "a", "b", 1, keyring);
    OSERROR(key, "add_key");

    ret = keyctl(KEYCTL_SESSION_TO_PARENT);
    OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");

    return 0;
    }

    Compiled and linked with -lkeyutils, you should see something like:

    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: _ses
    355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
    [dhowells@andromeda ~]$ /tmp/newpag
    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: _ses
    1055658746 --alswrv 4043 4043 \_ user: a
    [dhowells@andromeda ~]$ /tmp/newpag hello
    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: hello
    340417692 --alswrv 4043 4043 \_ user: a

    Where the test program creates a new session keyring, sticks a user key named
    'a' into it and then installs it on its parent.

    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     
  • e0e817392   CRED: Add some configurable debugging [try #6] ... Browse Code »

    Add a config option (CONFIG_DEBUG_CREDENTIALS) to turn on some debug checking
    for credential management. The additional code keeps track of the number of
    pointers from task_structs to any given cred struct, and checks to see that
    this number never exceeds the usage count of the cred struct (which includes
    all references, not just those from task_structs).

    Furthermore, if SELinux is enabled, the code also checks that the security
    pointer in the cred struct is never seen to be invalid.

    This attempts to catch the bug whereby inode_has_perm() faults in an nfsd
    kernel thread on seeing cred->security be a NULL pointer (it appears that the
    credential struct has been previously released):

    http://www.kerneloops.org/oops.php?number=252883

    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

11 May, 2009

1 commit

10 Jan, 2009

3 commits