05 May, 2010

5 commits

  • call_sbin_request_key() creates a keyring and then attempts to insert a link to
    the authorisation key into that keyring, but does so without holding a write
    lock on the keyring semaphore.

    It will normally get away with this because it hasn't told anyone that the
    keyring exists yet. The new keyring, however, has had its serial number
    published, which means it can be accessed directly by that handle.

    This was found by a previous patch that adds RCU lockdep checks to the code
    that reads the keyring payload pointer, which includes a check that the keyring
    semaphore is actually locked.

    Without this patch, the following command:

    keyctl request2 user b a @s

    will provoke the following lockdep warning is displayed in dmesg:

    ===================================================
    [ INFO: suspicious rcu_dereference_check() usage. ]
    ---------------------------------------------------
    security/keys/keyring.c:727 invoked rcu_dereference_check() without protection!

    other info that might help us debug this:

    rcu_scheduler_active = 1, debug_locks = 0
    2 locks held by keyctl/2076:
    #0: (key_types_sem){.+.+.+}, at: [] key_type_lookup+0x1c/0x71
    #1: (keyring_serialise_link_sem){+.+.+.}, at: [] __key_link+0x4d/0x3c5

    stack backtrace:
    Pid: 2076, comm: keyctl Not tainted 2.6.34-rc6-cachefs #54
    Call Trace:
    [] lockdep_rcu_dereference+0xaa/0xb2
    [] ? __key_link+0x4d/0x3c5
    [] __key_link+0x19e/0x3c5
    [] ? __key_instantiate_and_link+0xb1/0xdc
    [] ? key_instantiate_and_link+0x42/0x5f
    [] call_sbin_request_key+0xe7/0x33b
    [] ? mutex_unlock+0x9/0xb
    [] ? __key_instantiate_and_link+0xb1/0xdc
    [] ? key_instantiate_and_link+0x42/0x5f
    [] ? request_key_auth_new+0x1c2/0x23c
    [] ? cache_alloc_debugcheck_after+0x108/0x173
    [] ? request_key_and_link+0x146/0x300
    [] ? kmem_cache_alloc+0xe1/0x118
    [] request_key_and_link+0x28b/0x300
    [] sys_request_key+0xf7/0x14a
    [] ? trace_hardirqs_on_caller+0x10c/0x130
    [] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [] system_call_fastpath+0x16/0x1b

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

    David Howells
     
  • The keyring key type code should use RCU dereference wrappers, even when it
    holds the keyring's key semaphore.

    Reported-by: Vegard Nossum
    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • find_keyring_by_name() can gain access to a keyring that has had its reference
    count reduced to zero, and is thus ready to be freed. This then allows the
    dead keyring to be brought back into use whilst it is being destroyed.

    The following timeline illustrates the process:

    |(cleaner) (user)
    |
    | free_user(user) sys_keyctl()
    | | |
    | key_put(user->session_keyring) keyctl_get_keyring_ID()
    | || //=> keyring->usage = 0 |
    | |schedule_work(&key_cleanup_task) lookup_user_key()
    | || |
    | kmem_cache_free(,user) |
    | . |[KEY_SPEC_USER_KEYRING]
    | . install_user_keyrings()
    | . ||
    | key_cleanup() [serial_node,) } ||
    | | ||
    | [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
    | | |||
    | keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
    | || |||
    | |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
    | |. ||| *** GET freeing keyring ***
    | |. ||[read_unlock(&keyring_name_lock)]
    | || ||
    | |list_del() |[mutex_unlock(&key_user_k..mutex)]
    | || |
    | |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
    | | .
    | kmem_cache_free(,keyring) .
    | .
    | atomic_dec(&keyring->usage)
    v *** DESTROYED ***
    TIME

    If CONFIG_SLUB_DEBUG=y then we may see the following message generated:

    =============================================================================
    BUG key_jar: Poison overwritten
    -----------------------------------------------------------------------------

    INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
    INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
    INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
    INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
    INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300

    Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
    Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk

    Alternatively, we may see a system panic happen, such as:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
    IP: [] kmem_cache_alloc+0x5b/0xe9
    PGD 6b2b4067 PUD 6a80d067 PMD 0
    Oops: 0000 [#1] SMP
    last sysfs file: /sys/kernel/kexec_crash_loaded
    CPU 1
    ...
    Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
    RIP: 0010:[] [] kmem_cache_alloc+0x5b/0xe9
    RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002
    RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
    RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
    RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
    R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
    FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
    Stack:
    0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
    0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
    0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
    Call Trace:
    [] ? get_empty_filp+0x70/0x12f
    [] ? do_filp_open+0x145/0x590
    [] ? tlb_finish_mmu+0x2a/0x33
    [] ? unmap_region+0xd3/0xe2
    [] ? virt_to_head_page+0x9/0x2d
    [] ? alloc_fd+0x69/0x10e
    [] ? do_sys_open+0x56/0xfc
    [] ? system_call_fastpath+0x16/0x1b
    Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
    RIP [] kmem_cache_alloc+0x5b/0xe9

    This problem is that find_keyring_by_name does not confirm that the keyring is
    valid before accepting it.

    Skipping keyrings that have been reduced to a zero count seems the way to go.
    To this end, use atomic_inc_not_zero() to increment the usage count and skip
    the candidate keyring if that returns false.

    The following script _may_ cause the bug to happen, but there's no guarantee
    as the window of opportunity is small:

    #!/bin/sh
    LOOP=100000
    USER=dummy_user
    /bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
    for ((i=0; i&/dev/null

    as that uses a keyring named "foo" rather than relying on the user and
    user-session named keyrings.

    Reported-by: Toshiyuki Okajima
    Signed-off-by: David Howells
    Tested-by: Toshiyuki Okajima
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Toshiyuki Okajima
     
  • key_gc_keyring() needs to either hold the RCU read lock or hold the keyring
    semaphore if it's going to scan the keyring's list. Given that it only needs
    to read the key list, and it's doing so under a spinlock, the RCU read lock is
    the thing to use.

    Furthermore, the RCU check added in e7b0a61b7929632d36cf052d9e2820ef0a9c1bfe is
    incorrect as holding the spinlock on key_serial_lock is not grounds for
    assuming a keyring's pointer list can be read safely. Instead, a simple
    rcu_dereference() inside of the previously mentioned RCU read lock is what we
    want.

    Reported-by: Serge E. Hallyn
    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Acked-by: "Paul E. McKenney"
    Signed-off-by: James Morris

    David Howells
     
  • Fix an RCU warning in the reading of user keys:

    ===================================================
    [ INFO: suspicious rcu_dereference_check() usage. ]
    ---------------------------------------------------
    security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!

    other info that might help us debug this:

    rcu_scheduler_active = 1, debug_locks = 0
    1 lock held by keyctl/3637:
    #0: (&key->sem){+++++.}, at: [] keyctl_read_key+0x9c/0xcf

    stack backtrace:
    Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
    Call Trace:
    [] lockdep_rcu_dereference+0xaa/0xb2
    [] user_read+0x47/0x91
    [] keyctl_read_key+0xac/0xcf
    [] sys_keyctl+0x75/0xb7
    [] system_call_fastpath+0x16/0x1b

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

    David Howells
     

28 Apr, 2010

3 commits

  • …s/security-testing-2.6

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
    keys: don't need to use RCU in keyring_read() as semaphore is held

    Linus Torvalds
     
  • The request_key() system call and request_key_and_link() should make a
    link from an existing key to the destination keyring (if supplied), not
    just from a new key to the destination keyring.

    This can be tested by:

    ring=`keyctl newring fred @s`
    keyctl request2 user debug:a a
    keyctl request user debug:a $ring
    keyctl list $ring

    If it says:

    keyring is empty

    then it didn't work. If it shows something like:

    1 key in keyring:
    1070462727: --alswrv 0 0 user: debug:a

    then it did.

    request_key() system call is meant to recursively search all your keyrings for
    the key you desire, and, optionally, if it doesn't exist, call out to userspace
    to create one for you.

    If request_key() finds or creates a key, it should, optionally, create a link
    to that key from the destination keyring specified.

    Therefore, if, after a successful call to request_key() with a desination
    keyring specified, you see the destination keyring empty, the code didn't work
    correctly.

    If you see the found key in the keyring, then it did - which is what the patch
    is required for.

    Signed-off-by: David Howells
    Cc: James Morris
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • keyring_read() doesn't need to use rcu_dereference() to access the keyring
    payload as the caller holds the key semaphore to prevent modifications
    from happening whilst the data is read out.

    This should solve the following warning:

    ===================================================
    [ INFO: suspicious rcu_dereference_check() usage. ]
    ---------------------------------------------------
    security/keys/keyring.c:204 invoked rcu_dereference_check() without protection!

    other info that might help us debug this:

    rcu_scheduler_active = 1, debug_locks = 0
    1 lock held by keyctl/2144:
    #0: (&key->sem){+++++.}, at: [] keyctl_read_key+0x9c/0xcf

    stack backtrace:
    Pid: 2144, comm: keyctl Not tainted 2.6.34-rc2-cachefs #113
    Call Trace:
    [] lockdep_rcu_dereference+0xaa/0xb2
    [] keyring_read+0x4d/0xe7
    [] keyctl_read_key+0xac/0xcf
    [] sys_keyctl+0x75/0xb9
    [] system_call_fastpath+0x16/0x1b

    Signed-off-by: David Howells
    Cc: Herbert Xu
    Signed-off-by: Andrew Morton
    Signed-off-by: James Morris

    David Howells
     

25 Apr, 2010

1 commit

  • Fix the following RCU warning:

    ===================================================
    [ INFO: suspicious rcu_dereference_check() usage. ]
    ---------------------------------------------------
    security/keys/request_key.c:116 invoked rcu_dereference_check() without protection!

    This was caused by doing:

    [root@andromeda ~]# keyctl newring fred @s
    539196288
    [root@andromeda ~]# keyctl request2 user a a 539196288
    request_key: Required key not available

    Signed-off-by: David Howells
    Acked-by: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

22 Apr, 2010

1 commit


15 Apr, 2010

1 commit

  • Reduce MAX_AVTAB_HASH_BITS so that the avtab allocation is an order 2
    allocation rather than an order 4 allocation on x86_64. This
    addresses reports of page allocation failures:
    http://marc.info/?l=selinux&m=126757230625867&w=2
    https://bugzilla.redhat.com/show_bug.cgi?id=570433

    Reported-by: Russell Coker
    Signed-off-by: Stephen D. Smalley
    Acked-by: Eric Paris
    Signed-off-by: James Morris

    Stephen Smalley
     

30 Mar, 2010

1 commit

  • …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
     

15 Mar, 2010

1 commit


08 Mar, 2010

1 commit


05 Mar, 2010

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: (52 commits)
    init: Open /dev/console from rootfs
    mqueue: fix typo "failues" -> "failures"
    mqueue: only set error codes if they are really necessary
    mqueue: simplify do_open() error handling
    mqueue: apply mathematics distributivity on mq_bytes calculation
    mqueue: remove unneeded info->messages initialization
    mqueue: fix mq_open() file descriptor leak on user-space processes
    fix race in d_splice_alias()
    set S_DEAD on unlink() and non-directory rename() victims
    vfs: add NOFOLLOW flag to umount(2)
    get rid of ->mnt_parent in tomoyo/realpath
    hppfs can use existing proc_mnt, no need for do_kern_mount() in there
    Mirror MS_KERNMOUNT in ->mnt_flags
    get rid of useless vfsmount_lock use in put_mnt_ns()
    Take vfsmount_lock to fs/internal.h
    get rid of insanity with namespace roots in tomoyo
    take check for new events in namespace (guts of mounts_poll()) to namespace.c
    Don't mess with generic_permission() under ->d_lock in hpfs
    sanitize const/signedness for udf
    nilfs: sanitize const/signedness in dealing with ->d_name.name
    ...

    Fix up fairly trivial (famous last words...) conflicts in
    drivers/infiniband/core/uverbs_main.c and security/tomoyo/realpath.c

    Linus Torvalds
     

04 Mar, 2010

3 commits


01 Mar, 2010

2 commits

  • James Morris
     
  • * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (44 commits)
    rcu: Fix accelerated GPs for last non-dynticked CPU
    rcu: Make non-RCU_PROVE_LOCKING rcu_read_lock_sched_held() understand boot
    rcu: Fix accelerated grace periods for last non-dynticked CPU
    rcu: Export rcu_scheduler_active
    rcu: Make rcu_read_lock_sched_held() take boot time into account
    rcu: Make lockdep_rcu_dereference() message less alarmist
    sched, cgroups: Fix module export
    rcu: Add RCU_CPU_STALL_VERBOSE to dump detailed per-task information
    rcu: Fix rcutorture mod_timer argument to delay one jiffy
    rcu: Fix deadlock in TREE_PREEMPT_RCU CPU stall detection
    rcu: Convert to raw_spinlocks
    rcu: Stop overflowing signed integers
    rcu: Use canonical URL for Mathieu's dissertation
    rcu: Accelerate grace period if last non-dynticked CPU
    rcu: Fix citation of Mathieu's dissertation
    rcu: Documentation update for CONFIG_PROVE_RCU
    security: Apply lockdep-based checking to rcu_dereference() uses
    idr: Apply lockdep-based diagnostics to rcu_dereference() uses
    radix-tree: Disable RCU lockdep checking in radix tree
    vfs: Abstract rcu_dereference_check for files-fdtable use
    ...

    Linus Torvalds
     

26 Feb, 2010

2 commits


25 Feb, 2010

3 commits

  • Apply lockdep-ified RCU primitives to key_gc_keyring() and
    keyring_destroy().

    Cc: David Howells
    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josh@joshtriplett.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    Cc: Valdis.Kletnieks@vt.edu
    Cc: dhowells@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     
  • This fixes corrupted CIPSO packets when SELinux categories greater than 127
    are used. The bug occured on the second (and later) loops through the
    while; the inner for loop through the ebitmap->maps array used the same
    index as the NetLabel catmap->bitmap array, even though the NetLabel bitmap
    is twice as long as the SELinux bitmap.

    Signed-off-by: Joshua Roys
    Acked-by: Paul Moore
    Signed-off-by: James Morris

    Joshua Roys
     
  • If radix_tree_preload is failed in ima_inode_alloc, we don't need
    radix_tree_preload_end because kernel is alread preempt enabled

    Signed-off-by: Xiaotian Feng
    Signed-off-by: Mimi Zohar
    Signed-off-by: James Morris

    Xiaotian Feng
     

24 Feb, 2010

1 commit

  • Enhance the security framework to support resetting the active security
    module. This eliminates the need for direct use of the security_ops and
    default_security_ops variables outside of security.c, so make security_ops
    and default_security_ops static. Also remove the secondary_ops variable as
    a cleanup since there is no use for that. secondary_ops was originally used by
    SELinux to call the "secondary" security module (capability or dummy),
    but that was replaced by direct calls to capability and the only
    remaining use is to save and restore the original security ops pointer
    value if SELinux is disabled by early userspace based on /etc/selinux/config.
    Further, if we support this directly in the security framework, then we can
    just use &default_security_ops for this purpose since that is now available.

    Signed-off-by: Zhitong Wang
    Acked-by: Stephen Smalley
    Signed-off-by: James Morris

    wzt.wzt@gmail.com
     

22 Feb, 2010

1 commit

  • This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
    which removed a part of type_attribute_bounds_av as a dead code.
    However, at that time, we didn't find out the target side boundary allows
    to handle some of pseudo /proc//* entries with its process's security
    context well.

    Signed-off-by: KaiGai Kohei
    Acked-by: Stephen Smalley

    --
    security/selinux/ss/services.c | 43 ++++++++++++++++++++++++++++++++++++---
    1 files changed, 39 insertions(+), 4 deletions(-)
    Signed-off-by: James Morris

    KaiGai Kohei
     

17 Feb, 2010

1 commit


16 Feb, 2010

4 commits


15 Feb, 2010

4 commits

  • This patch adds garbage collector support to TOMOYO.
    Elements are protected by "struct srcu_struct tomoyo_ss".

    Signed-off-by: Tetsuo Handa
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Tetsuo Handa
     
  • Add refcounter to "struct tomoyo_domain_info" since garbage collector needs to
    determine whether this struct is referred by "struct cred"->security or not.

    Signed-off-by: Tetsuo Handa
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Tetsuo Handa
     
  • Gather structures and constants scattered around security/tomoyo/ directory.
    This is for preparation for adding garbage collector since garbage collector
    needs to know structures and constants which TOMOYO uses.

    Signed-off-by: Tetsuo Handa
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Tetsuo Handa
     
  • Add refcounter to "struct tomoyo_name_entry" and replace tomoyo_save_name()
    with tomoyo_get_name()/tomoyo_put_name() pair so that we can kfree() when
    garbage collector is added.

    Signed-off-by: Tetsuo Handa
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Tetsuo Handa
     

11 Feb, 2010

1 commit


09 Feb, 2010

1 commit

  • In sel_make_bools, kernel allocates memory for bool_pending_names[i]
    with security_get_bools. So if we just free bool_pending_names, those
    memories for bool_pending_names[i] will be leaked.

    This patch resolves dozens of following kmemleak report after resuming
    from suspend:
    unreferenced object 0xffff88022e4c7380 (size 32):
    comm "init", pid 1, jiffies 4294677173
    backtrace:
    [] create_object+0x1a2/0x2a9
    [] kmemleak_alloc+0x26/0x4b
    [] __kmalloc+0x18f/0x1b8
    [] security_get_bools+0xd7/0x16f
    [] sel_write_load+0x12e/0x62b
    [] vfs_write+0xae/0x10b
    [] sys_write+0x4a/0x6e
    [] system_call_fastpath+0x16/0x1b
    [] 0xffffffffffffffff

    Signed-off-by: Xiaotian Feng
    Signed-off-by: James Morris

    Xiaotian Feng
     

08 Feb, 2010

1 commit

  • Since list elements are rounded up to kmalloc() size rather than sizeof(int),
    saving one byte by using bitfields is no longer helpful.

    Signed-off-by: Tetsuo Handa
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Tetsuo Handa
     

07 Feb, 2010

1 commit