Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 1月, 2017 1 次提交
    • T
      AppArmor: Use GFP_KERNEL for __aa_kvmalloc(). · a7f6c1b6
      由 Tetsuo Handa 提交于 
      Calling kmalloc(GFP_NOIO) with order == PAGE_ALLOC_COSTLY_ORDER is not
recommended because it might fall into infinite retry loop without
invoking the OOM killer.

Since aa_dfa_unpack() is the only caller of kvzalloc() and
aa_dfa_unpack() which is calling kvzalloc() via unpack_table() is
doing kzalloc(GFP_KERNEL), it is safe to use GFP_KERNEL from
__aa_kvmalloc().

Since aa_simple_write_to_buffer() is the only caller of kvmalloc()
and aa_simple_write_to_buffer() is calling copy_from_user() which
is GFP_KERNEL context (see memdup_user_nul()), it is safe to use
GFP_KERNEL from __aa_kvmalloc().

Therefore, replace GFP_NOIO with GFP_KERNEL. Also, since we have
vmalloc() fallback, add __GFP_NORETRY so that we don't invoke the OOM
killer by kmalloc(GFP_KERNEL) with order == PAGE_ALLOC_COSTLY_ORDER.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      a7f6c1b6
  3. 25 12月, 2016 1 次提交
  5. 21 12月, 2016 9 次提交
  7. 15 12月, 2016 1 次提交
    • L
      mm: add locked parameter to get_user_pages_remote() · 5b56d49f
      由 Lorenzo Stoakes 提交于 
      Patch series "mm: unexport __get_user_pages_unlocked()".

This patch series continues the cleanup of get_user_pages*() functions
taking advantage of the fact we can now pass gup_flags as we please.

It firstly adds an additional 'locked' parameter to
get_user_pages_remote() to allow for its callers to utilise
VM_FAULT_RETRY functionality.  This is necessary as the invocation of
__get_user_pages_unlocked() in process_vm_rw_single_vec() makes use of
this and no other existing higher level function would allow it to do
so.

Secondly existing callers of __get_user_pages_unlocked() are replaced
with the appropriate higher-level replacement -
get_user_pages_unlocked() if the current task and memory descriptor are
referenced, or get_user_pages_remote() if other task/memory descriptors
are referenced (having acquiring mmap_sem.)

This patch (of 2):

Add a int *locked parameter to get_user_pages_remote() to allow
VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().

Taking into account the previous adjustments to get_user_pages*()
functions allowing for the passing of gup_flags, we are now in a
position where __get_user_pages_unlocked() need only be exported for his
ability to allow VM_FAULT_RETRY behaviour, this adjustment allows us to
subsequently unexport __get_user_pages_unlocked() as well as allowing
for future flexibility in the use of get_user_pages_remote().

[sfr@canb.auug.org.au: merge fix for get_user_pages_remote API change]
  Link: http://lkml.kernel.org/r/20161122210511.024ec341@canb.auug.org.au
Link: http://lkml.kernel.org/r/20161027095141.2569-2-lstoakes@gmail.comSigned-off-by: NLorenzo Stoakes <lstoakes@gmail.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krcmar <rkrcmar@redhat.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b56d49f
  9. 06 12月, 2016 1 次提交
    • A
      [iov_iter] new primitives - copy_from_iter_full() and friends · cbbd26b8
      由 Al Viro 提交于 
      copy_from_iter_full(), copy_from_iter_full_nocache() and
csum_and_copy_from_iter_full() - counterparts of copy_from_iter()
et.al., advancing iterator only in case of successful full copy
and returning whether it had been successful or not.

Convert some obvious users.  *NOTE* - do not blindly assume that
something is a good candidate for those unless you are sure that
not advancing iov_iter in failure case is the right thing in
this case.  Anything that does short read/short write kind of
stuff (or is in a loop, etc.) is unlikely to be a good one.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      cbbd26b8
  11. 05 12月, 2016 2 次提交
    • J
      Yama: allow access for the current ptrace parent · 50523a29
      由 Josh Stone 提交于 
      Under ptrace_scope=1, it's possible to have a tracee that is already
ptrace-attached, but is no longer a direct descendant.  For instance, a
forking daemon will be re-parented to init, losing its ancestry to the
tracer that launched it.

The tracer can continue using ptrace in that state, but it will be
denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
and various procfs files.  There's no reason to prevent such access for
a tracer that already has ptrace control anyway.

This patch adds a case to ptracer_exception_found to allow access for
any task in the same thread group as the current ptrace parent.
Signed-off-by: NJosh Stone <jistone@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      50523a29
    • A
      don't open-code file_inode() · 45063097
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45063097
  13. 03 12月, 2016 1 次提交
  15. 23 11月, 2016 1 次提交
    • A
      selinux: Convert isec->lock into a spinlock · 9287aed2
      由 Andreas Gruenbacher 提交于 
      Convert isec->lock from a mutex into a spinlock.  Instead of holding
the lock while sleeping in inode_doinit_with_dentry, set
isec->initialized to LABEL_PENDING and release the lock.  Then, when
the sid has been determined, re-acquire the lock.  If isec->initialized
is still set to LABEL_PENDING, set isec->sid; otherwise, the sid has
been set by another task (LABEL_INITIALIZED) or invalidated
(LABEL_INVALID) in the meantime.

This fixes a deadlock on gfs2 where

 * one task is in inode_doinit_with_dentry -> gfs2_getxattr, holds
   isec->lock, and tries to acquire the inode's glock, and

 * another task is in do_xmote -> inode_go_inval ->
   selinux_inode_invalidate_secctx, holds the inode's glock, and
   tries to acquire isec->lock.
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
[PM: minor tweaks to keep checkpatch.pl happy]
Signed-off-by: NPaul Moore <paul@paul-moore.com>
      9287aed2
  17. 22 11月, 2016 1 次提交
    • S
      selinux: keep SELinux in sync with new capability definitions · 3322d0d6
      由 Stephen Smalley 提交于 
      When a new capability is defined, SELinux needs to be updated.
Trigger a build error if a new capability is defined without
corresponding update to security/selinux/include/classmap.h's
COMMON_CAP2_PERMS.  This is similar to BUILD_BUG_ON() guards
in the SELinux nlmsgtab code to ensure that SELinux tracks
new netlink message types as needed.

Note that there is already a similar build guard in
security/selinux/hooks.c to detect when more than 64
capabilities are defined, since that will require adding
a third capability class to SELinux.

A nicer way to do this would be to extend scripts/selinux/genheaders
or a similar tool to auto-generate the necessary definitions and code
for SELinux capability checking from include/uapi/linux/capability.h.
AppArmor does something similar in its Makefile, although it only
needs to generate a single table of names.  That is left as future
work.
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
[PM: reformat the description to keep checkpatch.pl happy]
Signed-off-by: NPaul Moore <paul@paul-moore.com>
      3322d0d6
  19. 21 11月, 2016 2 次提交
  21. 16 11月, 2016 2 次提交
  23. 15 11月, 2016 5 次提交
  25. 14 11月, 2016 4 次提交
  27. 11 11月, 2016 4 次提交
    • C
      Smack: ipv6 label match fix · 2e4939f7
      由 Casey Schaufler 提交于 
      The check for a deleted entry in the list of IPv6 host
addresses was being performed in the wrong place, leading
to most peculiar results in some cases. This puts the
check into the right place.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      2e4939f7
    • H
      SMACK: Fix the memory leak in smack_cred_prepare() hook · b437aba8
      由 Himanshu Shukla 提交于 
      Memory leak in smack_cred_prepare()function.
smack_cred_prepare() hook returns error if there is error in allocating
memory in smk_copy_rules() or smk_copy_relabel() function.
If smack_cred_prepare() function returns error then the calling
function should call smack_cred_free() function for cleanup.
In smack_cred_free() function first credential is  extracted and
then all rules are deleted. In smack_cred_prepare() function security
field is assigned in the end when all function return success. But this
function may return before and memory will not be freed.
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      b437aba8
    • H
      SMACK: Do not apply star label in smack_setprocattr hook · 7128ea15
      由 Himanshu Shukla 提交于 
      Smack prohibits processes from using the star ("*") and web ("@") labels.
Checks have been added in other functions. In smack_setprocattr()
hook, only check for web ("@") label has been added and restricted
from applying web ("@") label.
Check for star ("*") label should also be added in smack_setprocattr()
hook. Return error should be "-EINVAL" not "-EPERM" as permission
is there for setting label but not the label value as star ("*") or
web ("@").
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      7128ea15
    • H
      smack: parse mnt opts after privileges check · 2097f599
      由 Himanshu Shukla 提交于 
      In smack_set_mnt_opts()first the SMACK mount options are being
parsed and later it is being checked whether the user calling
mount has CAP_MAC_ADMIN capability.
This sequence of operationis will allow unauthorized user to add
SMACK labels in label list and may cause denial of security attack
by adding many labels by allocating kernel memory by unauthorized user.
Superblock smack flag is also being set as initialized though function
may return with EPERM error.
First check the capability of calling user then set the SMACK attributes
and smk_flags.
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      2097f599
  29. 05 11月, 2016 1 次提交
  31. 27 10月, 2016 3 次提交
    • A
      security/keys: make BIG_KEYS dependent on stdrng. · 31e6ec45
      由 Artem Savkov 提交于 
      Since BIG_KEYS can't be compiled as module it requires one of the "stdrng"
providers to be compiled into kernel. Otherwise big_key_crypto_init() fails
on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in
big_key_preparse()) results in a NULL pointer dereference.

Fixes: 13100a72 ('Security: Keys: Big keys stored encrypted')
Signed-off-by: NArtem Savkov <asavkov@redhat.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Kirill Marinushkin <k.marinushkin@gmail.com>
cc: stable@vger.kernel.org
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      31e6ec45
    • D
      KEYS: Sort out big_key initialisation · 7df3e59c
      由 David Howells 提交于 
      big_key has two separate initialisation functions, one that registers the
key type and one that registers the crypto.  If the key type fails to
register, there's no problem if the crypto registers successfully because
there's no way to reach the crypto except through the key type.

However, if the key type registers successfully but the crypto does not,
big_key_rng and big_key_blkcipher may end up set to NULL - but the code
neither checks for this nor unregisters the big key key type.

Furthermore, since the key type is registered before the crypto, it is
theoretically possible for the kernel to try adding a big_key before the
crypto is set up, leading to the same effect.

Fix this by merging big_key_crypto_init() and big_key_init() and calling
the resulting function late.  If they're going to be encrypted, we
shouldn't be creating big_keys before we have the facilities to do the
encryption available.  The key type registration is also moved after the
crypto initialisation.

The fix also includes message printing on failure.

If the big_key type isn't correctly set up, simply doing:

	dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s

ought to cause an oops.

Fixes: 13100a72 ('Security: Keys: Big keys stored encrypted')
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Peter Hlavaty <zer0mem@yahoo.com>
cc: Kirill Marinushkin <k.marinushkin@gmail.com>
cc: Artem Savkov <asavkov@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      7df3e59c
    • D
      KEYS: Fix short sprintf buffer in /proc/keys show function · 03dab869
      由 David Howells 提交于 
      This fixes CVE-2016-7042.

Fix a short sprintf buffer in proc_keys_show().  If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.

The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:

	(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
	$2 = 30500568904943

That's 14 chars plus NUL, not 11 chars plus NUL.

Expand the buffer to 16 chars.

I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.

The panic incurred looks something like:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
 ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
 ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
 [<ffffffff813d941f>] dump_stack+0x63/0x84
 [<ffffffff811b2cb6>] panic+0xde/0x22a
 [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
 [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
 [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
 [<ffffffff81350410>] ? key_validate+0x50/0x50
 [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
 [<ffffffff8126b31c>] seq_read+0x2cc/0x390
 [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
 [<ffffffff81244fc7>] __vfs_read+0x37/0x150
 [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
 [<ffffffff81246156>] vfs_read+0x96/0x130
 [<ffffffff81247635>] SyS_read+0x55/0xc0
 [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
Reported-by: NOndrej Kozina <okozina@redhat.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NOndrej Kozina <okozina@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      03dab869
  33. 20 10月, 2016 1 次提交