Merge #1

AndroiableDroid · 2017-12-15T15:10:07Z

No description provided.

Fail cases of accept() system call on AF_MSM_IPC socket family causes NULL pointer de-reference of sock structure variable in release operation. Validate the sock structure pointer before using it in release operation. CRs-Fixed: 1068888 Change-Id: I5637e52be59ea9504ea6ae317394bef0c28c7865 Signed-off-by: Arun Kumar Neelakantam <[email protected]>

The overflow check is required to ensure that user space data in kernel may not go beyond buffer boundary CRs-Fixed: 1064411 Change-Id: I54c28a8942cf1a6a47a4e8272f3159b35d753ead Signed-off-by: Karthik Reddy Katta <[email protected]>

BUG: 27577101 BUG: 27532522 Change-Id: If0c03fa24270cd3683db482a599fc39e9fec1ac9 Signed-off-by: Mohamad Ayyash <[email protected]> Git-commit: d85e322ff3bc8d7aa872ad12df6427dd236e540a Git-repo: https://android.googlesource.com/kernel/common Signed-off-by: Ravi Kumar Siddojigari <[email protected]>

Initialize param length with user space argument and check the condition for maximum length in SND_AUDIOCODEC_EAC3 format. CRs-Fixed: 1032820 Change-Id: I710c1f743d7502e93989e8cc487078366570e723 Signed-off-by: Surendar karka <[email protected]>

dummy_codec is not initialized before use, which could cause kernel panic. Initialize dummy_codec before use. Change-Id: Iedf7a3accbd14138ab7ed9e4e36a98fd7ca9a839 Signed-off-by: Meng Wang <[email protected]>

Source and Destination addresses passed by user space apps/clients are validated independent of type of operation to mitigate kernel address space exploitation. Change-Id: I9ecb0103d7a73eedb2e0d1db1d5613b18dd77e59 Signed-off-by: AnilKumar Chimata <[email protected]>

The params array is used without initialization, which may cause security issues. Initialize it as all zero after the definition. CRs-Fixed: 1062271 Change-Id: If462fe3d82f139d72547f82dc7eb564f83cb35bf Signed-off-by: Walter Yang <[email protected]>

Verifying the i2c table index value before accessing the i2c table to avoid memory corruption issues. CRs-Fixed: 1065916 Change-Id: I0e31c22f90006f27a77cd420288334b8355cee95 Signed-off-by: Sureshnaidu Laveti <[email protected]> Signed-off-by: Suman Mukherjee <[email protected]>

There is a possible stack overflow vulnerability in the rmidev_write function because the stack array size is from user space. changes to allocate heap memory for the temporary buffer instead of stack memory to prevent the stack overflow vulnerability. As discussed under CVE-2016-3865 and ANDROID-28799389. Change-Id: I20f639e09aaf3c533c98a12a2413570feae3d6d0 Signed-off-by: Ravi Kumar Siddojigari <[email protected]> Signed-off-by: Shantanu Jain <[email protected]>

The fix from 9fc81d87420d ("perf: Fix events installation during moving group") was incomplete in that it failed to recognise that creating a group with events for different CPUs is semantically broken -- they cannot be co-scheduled. Furthermore, it leads to real breakage where, when we create an event for CPU Y and then migrate it to form a group on CPU X, the code gets confused where the counter is programmed -- triggered in practice as well by me via the perf fuzzer. Fix this by tightening the rules for creating groups. Only allow grouping of counters that can be co-scheduled in the same context. This means for the same task and/or the same cpu. Change-Id: I01d7b24b44fff039e72c80cca7f70158fa354470 Fixes: 9fc81d87420d ("perf: Fix events installation during moving group") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Git-commit: c3c87e770458aa004bd7ed3f29945ff436fd6511 Git-repo: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git Signed-off-by: Patrick Fay <[email protected]>

Change-Id: I74875bd7ad075e1e77dd82132be191e53e1eda02

(cherry pick from commit 89a0714106aac7309c7dfa0f004b39e1e89d2942) Create constants that define the maximum and minimum values representable by the kernel types u8, s8, u16, s16, and so on. Change-Id: I5b3f021c30454e6a6f188c74910d5758ccccccc9 Signed-off-by: Alex Elder <[email protected]> Cc: Sage Weil <[email protected]> Cc: David Miller <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Bug: 27299111 Bug: 27297988 Git-commit: 89a0714106aac7309c7dfa0f004b39e1e89d2942 Git-repo: https://android.googlesource.com/kernel/common [[email protected] fixed compilation errors] CRs-Fixed: 1064411 Signed-off-by: Swetha Chikkaboraiah <[email protected]>

Change-Id: Ia7660b0b3026ffa93e57338501d834e7766a9af3

Adding check for null function pointer for dummy sound driver read/write to prevent kernel panic. Issue: CYNGNOS-3304 Bug: 28838221 Change-Id: I32548a7e37869a17a5f88c646ddbfb8243cadcc0 Signed-off-by: Yuan Lin <[email protected]>

An elevation of privilege vulnerability in the Synaptics touchscreen driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process. This is CVE 2016 3940. Issue: CYNGNOS-3304 Change-Id: Ic6c2a5399965d9f305a95861ab329c3e94cc975a

An information disclosure vulnerability could enable a local malicious application to access data outside of its permission levels. This issue is rated as Moderate because it first requires compromising a privileged process. CVE_2016_6683 Issue: CYNGNOS-3304 Change-Id: I0318f5c9dbc8704a6fa3fbe1c14bca1a5244b810

The format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. Use %pK instead of %p, which also evaluates whether kptr_restrict is set. Bug: 30148243 Issue: CYNGNOS-3304 Change-Id: Ib1adf14e9620ad7b1bd3e962001c852610210d46 Signed-off-by: Divya Ponnusamy <[email protected]>

…llback (cherry picked from 951b6a0717db97ce420547222647bcc40bf1eacd) addr can be NULL and it should not be dereferenced before NULL checking. Issue: CYNGNOS-3304 Signed-off-by: Jaganath Kanakkassery <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Change-Id: I18bda54bb1427d9443a39a04a5c551720118dc26 Bug: 30149612

An elevation of privilege vulnerability in system_server could enable local malicious application to execute arbitrary code within the context of a privileged process. This issue is rated as High because it could be used to gain local access to elevated capabilities, which are not normally accessible to a third-party application. CVE_2016_6674 Issue: CYNGNOS-3304 Change-Id: Icc60d83aefdc55fb3502544cc00c7a4bbc0060b8

An elevation of privilege vulnerability in the Synaptics touchscreen driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process. CVE_2016_6672 Issue: CYNGNOS-3304 Change-Id: If27ed96bc9b04954fb3b054df4ba1a1795db70da

An information disclosure vulnerability in Binder could enable a local malicious application to access data outside of its permission levels. This issue is rated as Moderate because it first requires compromising a privileged process. CVE_2016_6689 Issue: CYNGNOS-3304 Change-Id: Ie26fa668f232dbd453fdc5aeb38eb8071eac19e9

IPA might have Information leak and device crash due to kernel heap overread in IPA driver when processing WAN_IOC_ADD_FLT_RULE_INDEX ioctl. The fix is to add check on max number of filter rules send to modem. Issue: CYNGNOS-3304 Change-Id: I454e04d05cfcb7af8fc4bd2b4a1bade55c4684d0 Signed-off-by: Skylar Chang <[email protected]>

The MSM_DMA_IOALLOC ioctl command allocates kernel memory and this memory can be read back using the MSM_DMA_IORBUF ioctl command. This memory is not zero-initialized and may contain sensitive data. Issue: CYNGNOS-3281 Change-Id: I8c55d6fe500e7607690b89806715893783eecf9c Signed-off-by: Srinivasarao P <[email protected]>

This reverts commit e623b152f30f6f1204919315df37244d69e5d55e. Change-Id: I8e8903786da86cbe4206c18f817fbb54db229472 Signed-off-by: Aravind Asam <[email protected]>

This reverts commit ba733f9857b966459316d0cd33b8da2e22f62d7d. Change-Id: Ie4d3e904160195dafd93a59a25d56b1449e8fc86 Signed-off-by: Aravind Asam <[email protected]>

(cherry pick from commit 83d4a806ae46397f606de7376b831524bd3a21e5) Commit f01e1af ("selinux: don't pass in NULL avd to avc_has_perm_noaudit") made this pointer reassignment unnecessary. Avd should continue to reference the stack-based copy. Signed-off-by: Jeff Vander Stoep <[email protected]> Acked-by: Stephen Smalley <[email protected]> [PM: tweaked subject line] Signed-off-by: Paul Moore <[email protected]> Bug: 22846070 Change-Id: I8fcba45a5acc4de862bd5b3f07bf4980f67133c4 Git-commit: b1b3844449d596e5f25f591d89611c7e57d32610 Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by: David Ng <[email protected]>

(cherry picked from commit fa1aa143ac4a682c7f5fd52a3cf05f5a6fe44a0a) Add extended permissions logic to selinux. Extended permissions provides additional permissions in 256 bit increments. Extend the generic ioctl permission check to use the extended permissions for per-command filtering. Source/target/class sets including the ioctl permission may additionally include a set of commands. Example: allowxperm <source> <target>:<class> ioctl unpriv_app_socket_cmds auditallowxperm <source> <target>:<class> ioctl priv_gpu_cmds Where unpriv_app_socket_cmds and priv_gpu_cmds are macros representing commonly granted sets of ioctl commands. When ioctl commands are omitted only the permissions are checked. This feature is intended to provide finer granularity for the ioctl permission that may be too imprecise. For example, the same driver may use ioctls to provide important and benign functionality such as driver version or socket type as well as dangerous capabilities such as debugging features, read/write/execute to physical memory or access to sensitive data. Per-command filtering provides a mechanism to reduce the attack surface of the kernel, and limit applications to the subset of commands required. The format of the policy binary has been modified to include ioctl commands, and the policy version number has been incremented to POLICYDB_VERSION_XPERMS_IOCTL=30 to account for the format change. The extended permissions logic is deliberately generic to allow components to be reused e.g. netlink filters Signed-off-by: Jeff Vander Stoep <[email protected]> Acked-by: Nick Kralevich <[email protected]> Signed-off-by: Paul Moore <[email protected]> Bug: 22846070 Change-Id: I7c6bdc0362657b47aa1388936c5a1300bc5c0b42 Git-commit: 05b7da58527ef14001fe2b6e8de6b01d895d4429 Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by: David Ng <[email protected]>

…bugfs - add "pstore" and "debugfs" to list of in-core exceptions - change fstype checks to boolean equation - change from strncmp to strcmp for checking (Cherry Pick from commit 2294d499b7969df3838becf5e58bf16b0e3c86c8) Signed-off-by: Mark Salyzyn <[email protected]> Signed-off-by: Bharat Pawar <[email protected]> Bug: 18917345 Bug: 18935184 Change-Id: Ib648f30ce4b5d6c96f11465836d6fee89bec1c72

NOT intended for new Android devices - this commit is unnecessary for a target device that does not have a previous M variant. DO NOT upstream. Android only. Motivation: This commit mitigates a mismatch between selinux kernel and selinux userspace. The selinux ioctl white-listing binary policy format that was accepted into Android M differs slightly from what was later accepted into the upstream kernel. This leaves Android master branch kernels incompatible with Android M releases. This patch restores backwards compatibility. This is important because: 1. kernels may be updated on a different cycle than the rest of the OS e.g. security patching. 2. Android M bringup may still be ongoing for some devices. The same kernel should work for both M and master. Backwards compatibility is achieved by checking for an Android M policy characteristic during initial policy read and converting to upstream policy format. The inverse conversion is done for policy write as required for CTS testing Bug: 22846070 Change-Id: I2f1ee2eee402f37cf3c9df9f9e03c1b9ddec1929 Signed-off-by: Jeff Vander Stoep <[email protected]> Signed-off-by: Bharat Pawar <[email protected]>

Use the ATTR_FILE attribute to distinguish between truncate() and ftruncate() system calls. The two other cases where do_truncate is called with a filp (and therefore ATTR_FILE is set) are for coredump files and for open(O_TRUNC). In both of those cases the open permission has already been checked during file open and therefore does not need to be repeated. Commit 95dbf73 ("SELinux: check OPEN on truncate calls") fixed a major issue where domains were allowed to truncate files without the open permission. However, it introduced a new bug where a domain with the write permission can no longer ftruncate files without the open permission, even when they receive an already open file. (cherry picked from commit b21800f304392ee5d20f411c37470183cc779f11) Bug: 22567870 Change-Id: I2525a0e244c8d635b2d0c1f966071edbb365a43a Signed-off-by: Jeff Vander Stoep <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Git-commit: e9e500827b871459306974c32a0b6398375ce7d5 Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by: David Ng <[email protected]> Signed-off-by: Aravind Asam <[email protected]> Signed-off-by: Bharat Pawar <[email protected]>

(cherry picked from commit commit f3bef67992e8698897b584616535803887c4a73e). commit fa1aa143ac4a ("selinux: extended permissions for ioctls") introduced a bug into the handling of conditional rules, skipping the processing entirely when the caller does not provide an extended permissions (xperms) structure. Access checks from userspace using /sys/fs/selinux/access do not include such a structure since that interface does not presently expose extended permission information. As a result, conditional rules were being ignored entirely on userspace access requests, producing denials when access was allowed by conditional rules in the policy. Fix the bug by only skipping computation of extended permissions in this situation, not the entire conditional rules processing. Change-Id: I24f39e3907d0b00a4194e15a4472e8d859508fa9 Reported-by: Laurent Bigonville <[email protected]> Signed-off-by: Stephen Smalley <[email protected]> [PM: fixed long lines in patch description] Cc: [email protected] # 4.3 Signed-off-by: Paul Moore <[email protected]> Git-commit: bd8d3dd3ae35f283f3b76e47b9762225c9f7d46c Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by: David Ng <[email protected]> Signed-off-by: Bharat Pawar <[email protected]>

There is a race condition when removing glue directory. It can be reproduced in following test: path 1: Add first child device device_add() get_device_parent() /*find parent from glue_dirs.list*/ list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) if (k->parent == parent_kobj) { kobj = kobject_get(k); break; } .... class_dir_create_and_add() path2: Remove last child device under glue dir device_del() cleanup_device_parent() cleanup_glue_dir() kobject_put(glue_dir); If path2 has been called cleanup_glue_dir(), but not call kobject_put(glue_dir), the glue dir is still in parent's kset list. Meanwhile, path1 find the glue dir from the glue_dirs.list. Path2 may release glue dir before path1 call kobject_get(). So kernel will report the warning and bug_on. This is a "classic" problem we have of a kref in a list that can be found while the last instance could be removed at the same time. This patch reuse gdp_mutex to fix this race condition. The following calltrace is captured in kernel 3.4, but the latest kernel still has this bug. ----------------------------------------------------- <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40() <4>[ 3965.441474] Hardware name: Romley <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)... ... <4>[ 3965.441605] Call Trace: <4>[ 3965.441611] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0 <4>[ 3965.441615] [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20 <4>[ 3965.441618] [<ffffffff81215963>] kobject_get+0x33/0x40 <4>[ 3965.441624] [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0 <4>[ 3965.441627] [<ffffffff812d22d4>] device_add+0xd4/0x6d0 <4>[ 3965.441631] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40 .... <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65! <4>[ 3965.441915] invalid opcode: 0000 [varunpilankar#1] SMP ... <4>[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10 <4>[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20 <4>[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120 <4>[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490 .... ------------------------------------------------------- Signed-off-by: Yijing Wang <[email protected]> Signed-off-by: Weng Meiling <[email protected]> Cc: <[email protected]> #3.4+ Signed-off-by: Greg Kroah-Hartman <[email protected]> Git-commit: e4a60d139060975eb956717e4f63ae348d4d8cc5 Git-repo: https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/ Change-Id: I99cc85e86b3a1599c885588788822c695a6bd493 Signed-off-by: Nirmal Abraham <[email protected]>

commit 7d8b6c63751cfbbe5eef81a48c22978b3407a3ad upstream. This is effectively a revert of 7b9a7ec plus fixing it a different way... We found, when trying to run an application from an application which had dropped privs that the kernel does security checks on undefined capability bits. This was ESPECIALLY difficult to debug as those undefined bits are hidden from /proc/$PID/status. Consider a root application which drops all capabilities from ALL 4 capability sets. We assume, since the application is going to set eff/perm/inh from an array that it will clear not only the defined caps less than CAP_LAST_CAP, but also the higher 28ish bits which are undefined future capabilities. The BSET gets cleared differently. Instead it is cleared one bit at a time. The problem here is that in security/commoncap.c::cap_task_prctl() we actually check the validity of a capability being read. So any task which attempts to 'read all things set in bset' followed by 'unset all things set in bset' will not even attempt to unset the undefined bits higher than CAP_LAST_CAP. So the 'parent' will look something like: CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffc000000000 All of this 'should' be fine. Given that these are undefined bits that aren't supposed to have anything to do with permissions. But they do... So lets now consider a task which cleared the eff/perm/inh completely and cleared all of the valid caps in the bset (but not the invalid caps it couldn't read out of the kernel). We know that this is exactly what the libcap-ng library does and what the go capabilities library does. They both leave you in that above situation if you try to clear all of you capapabilities from all 4 sets. If that root task calls execve() the child task will pick up all caps not blocked by the bset. The bset however does not block bits higher than CAP_LAST_CAP. So now the child task has bits in eff which are not in the parent. These are 'meaningless' undefined bits, but still bits which the parent doesn't have. The problem is now in cred_cap_issubset() (or any operation which does a subset test) as the child, while a subset for valid cap bits, is not a subset for invalid cap bits! So now we set durring commit creds that the child is not dumpable. Given it is 'more priv' than its parent. It also means the parent cannot ptrace the child and other stupidity. The solution here: 1) stop hiding capability bits in status This makes debugging easier! 2) stop giving any task undefined capability bits. it's simple, it you don't put those invalid bits in CAP_FULL_SET you won't get them in init and you won't get them in any other task either. This fixes the cap_issubset() tests and resulting fallout (which made the init task in a docker container untraceable among other things) 3) mask out undefined bits when sys_capset() is called as it might use ~0, ~0 to denote 'all capabilities' for backward/forward compatibility. This lets 'capsh --caps="all=eip" -- -c /bin/bash' run. 4) mask out undefined bit when we read a file capability off of disk as again likely all bits are set in the xattr for forward/backward compatibility. This lets 'setcap all+pe /bin/bash; /bin/bash' run Signed-off-by: Eric Paris <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Andrew Vagin <[email protected]> Cc: Andrew G. Morgan <[email protected]> Cc: Serge E. Hallyn <[email protected]> Cc: Kees Cook <[email protected]> Cc: Steve Grubb <[email protected]> Cc: Dan Walsh <[email protected]> Signed-off-by: James Morris <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

too many places open-code it Change-Id: I007f4b663d7af564b2ce4009f5e13eeeeb82929a Signed-off-by: Al Viro <[email protected]> Git-commit: 39f1f78d53b9bcbca91967380c5f0f2305a5c55f Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [[email protected]: Remove redundant apparmor code not present upstream] Signed-off-by: Jeremy Gebben <[email protected]>

Allow selecting PFT as the chosen LSM (Linux Security Module). Change-Id: I45f403535e72cf9374b0d8c0263f6f64e4d710e6 Signed-off-by: Amir Samuelov <[email protected]>

commit 3b1deef6b1289a99505858a3b212c5b50adf0c2f upstream. evm_inode_setxattr() can be called with no value. The function does not check the length so that following command can be used to produce the kernel oops: setfattr -n security.evm FOO. This patch fixes it. Changes in v3: * there is no reason to return different error codes for EVM_XATTR_HMAC and non EVM_XATTR_HMAC. Remove unnecessary test then. Changes in v2: * testing for validity of xattr type [ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1106.398192] IP: [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0 [ 1106.399953] Oops: 0000 [varunpilankar#1] SMP [ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse [ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936 [ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000 [ 1106.400020] RIP: 0010:[<ffffffff812af7b8>] [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP: 0018:ffff88002917fd50 EFLAGS: 00010246 [ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000 [ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8 [ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df [ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00 [ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1106.400020] FS: 00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000 [ 1106.400020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0 [ 1106.400020] Stack: [ 1106.400020] ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98 [ 1106.400020] ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000 [ 1106.400020] 0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8 [ 1106.400020] Call Trace: [ 1106.400020] [<ffffffff812a1030>] security_inode_setxattr+0x5d/0x6a [ 1106.400020] [<ffffffff8116d08a>] vfs_setxattr+0x6b/0x9f [ 1106.400020] [<ffffffff8116d1e0>] setxattr+0x122/0x16c [ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45 [ 1106.400020] [<ffffffff8114d011>] ? __sb_start_write+0x10f/0x143 [ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45 [ 1106.400020] [<ffffffff811687c0>] ? __mnt_want_write+0x48/0x4f [ 1106.400020] [<ffffffff8116d3e6>] SyS_setxattr+0x6e/0xb0 [ 1106.400020] [<ffffffff81529da9>] system_call_fastpath+0x16/0x1b [ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 <41> 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83 [ 1106.400020] RIP [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP <ffff88002917fd50> [ 1106.400020] CR2: 0000000000000000 [ 1106.428061] ---[ end trace ae08331628ba3050 ]--- Reported-by: Jan Kara <[email protected]> Signed-off-by: Dmitry Kasatkin <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 923190d32de4428afbea5e5773be86bea60a9925 upstream. sb_finish_set_opts() can race with inode_free_security() when initializing inode security structures for inodes created prior to initial policy load or by the filesystem during ->mount(). This appears to have always been a possible race, but commit 3dc91d4 ("SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()") made it more evident by immediately reusing the unioned list/rcu element of the inode security structure for call_rcu() upon an inode_free_security(). But the underlying issue was already present before that commit as a possible use-after-free of isec. Shivnandan Kumar reported the list corruption and proposed a patch to split the list and rcu elements out of the union as separate fields of the inode_security_struct so that setting the rcu element would not affect the list element. However, this would merely hide the issue and not truly fix the code. This patch instead moves up the deletion of the list entry prior to dropping the sbsec->isec_lock initially. Then, if the inode is dropped subsequently, there will be no further references to the isec. Reported-by: Shivnandan Kumar <[email protected]> Signed-off-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b26bdde5bb27f3f900e25a95e33a0c476c8c2c48 upstream. When loading encrypted-keys module, if the last check of aes_get_sizes() in init_encrypted() fails, the driver just returns an error without unregistering its key type. This results in the stale entry in the list. In addition to memory leaks, this leads to a kernel crash when registering a new key type later. This patch fixes the problem by swapping the calls of aes_get_sizes() and register_key_type(), and releasing resources properly at the error paths. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163 Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…g caches commit 615e51fdda6f274e94b1e905fcaf6111e0d9aa20 upstream. When flushing the AVC, such as during a policy load, the various network caches are also flushed, with each making a call to synchronize_net() which has shown to be expensive in some cases. This patch consolidates the network cache flushes into a single AVC callback which only calls synchronize_net() once for each AVC cache flush. Change-Id: I2a7f020748d1adf2b68246f6ef86d0c871adffb7 Reported-by: Jaejyn Shin <[email protected]> Signed-off-by: Paul Moore <[email protected]> Git-commit: 5b5b6febcab05ef9e8972ead4cc3cf8381d45a95 Signed-off-by: Ravi Kumar S <[email protected]>

commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream. When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6436a123a147db51a0b06024a8350f4c230e73ff upstream. Return a negative error value like the rest of the entries in this function. Signed-off-by: Joe Perches <[email protected]> Acked-by: Stephen Smalley <[email protected]> [PM: tweaked subject line] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09be ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by: Phil "not Paul" Oester <[email protected]> Acked-by: Hugh Dickins <[email protected]> Reviewed-by: Michal Hocko <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Kees Cook <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Willy Tarreau <[email protected]> Cc: Nick Piggin <[email protected]> Cc: Greg Thelen <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]> [wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask; s/faultin_page/__get_user_page] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Simao Gomes Viana <[email protected]> Revert "powerpc/tm: Always reclaim in start_thread() for exec() class syscalls" This reverts commit 8110080. Guenter noticed that this breaks PPC build when CONFIG_PPC_TRANSACTIONAL_MEM is set, because this patch was not for 3.10. Cc: Guenter Roeck <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> PCI: Support PCIe devices with short cfg_size commit c20aecf6963d1273d8f6d61c042b4845441ca592 upstream. If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by: Jason S. McMullan <[email protected]> [simon: edited changelog] Signed-off-by: Simon Horman <[email protected]> [bhelgaas: more changelog edits] Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> PCI: Add Netronome vendor and device IDs commit a755e169031dac9ebaed03302c4921687c271d62 upstream. Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by: Jason S. McMullan <[email protected]> [simon: edited changelog] Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> PCI: Limit config space size for Netronome NFP6000 family commit 9f33a2ae59f24452c1076749deb615bccd435ca9 upstream. The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by: Jason S. McMullan <[email protected]> [simon: edited changelog] Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> PCI: Add Netronome NFP4000 PF device ID commit 69874ec233871a62e1bc8c89e643993af93a8630 upstream. Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> PCI: Limit config space size for Netronome NFP4000 commit c2e771b02792d222cbcd9617fe71482a64f52647 upstream. Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> aacraid: Check size values after double-fetch from user commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 upstream. In aacraid's ioctl_send_fib() we do two fetches from userspace, one the get the fib header's size and one for the fib itself. Later we use the size field from the second fetch to further process the fib. If for some reason the size from the second fetch is different than from the first fix, we may encounter an out-of- bounds access in aac_fib_send(). We also check the sender size to insure it is not out of bounds. This was reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was assigned CVE-2016-6480. Reported-by: Pengfei Wang <[email protected]> Fixes: 7c00ffa '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)' Cc: [email protected] Signed-off-by: Dave Carroll <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> megaraid_sas: Fix probing cards without io port commit e7f851684efb3377e9c93aca7fae6e76212e5680 upstream. Found one megaraid_sas HBA probe fails, [ 187.235190] scsi host2: Avago SAS based MegaRAID driver [ 191.112365] megaraid_sas 0000:89:00.0: BAR 0: can't reserve [io 0x0000-0x00ff] [ 191.120548] megaraid_sas 0000:89:00.0: IO memory region busy! and the card has resource like, [ 125.097714] pci 0000:89:00.0: [1000:005d] type 00 class 0x010400 [ 125.104446] pci 0000:89:00.0: reg 0x10: [io 0x0000-0x00ff] [ 125.110686] pci 0000:89:00.0: reg 0x14: [mem 0xce400000-0xce40ffff 64bit] [ 125.118286] pci 0000:89:00.0: reg 0x1c: [mem 0xce300000-0xce3fffff 64bit] [ 125.125891] pci 0000:89:00.0: reg 0x30: [mem 0xce200000-0xce2fffff pref] that does not io port resource allocated from BIOS, and kernel can not assign one as io port shortage. The driver is only looking for MEM, and should not fail. It turns out megasas_init_fw() etc are using bar index as mask. index 1 is used as mask 1, so that pci_request_selected_regions() is trying to request BAR0 instead of BAR1. Fix all related reference. Fixes: b6d5d88 ("megaraid_sas: Use lowest memory bar for SR-IOV VF support") Signed-off-by: Yinghai Lu <[email protected]> Acked-by: Kashyap Desai <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> crypto: nx - off by one bug in nx_of_update_msc() commit e514cc0a492a3f39ef71b31590a7ef67537ee04b upstream. The props->ap[] array is defined like this: struct alg_props ap[NX_MAX_FC][NX_MAX_MODE][3]; So we can see that if msc->fc and msc->mode are == to NX_MAX_FC or NX_MAX_MODE then we're off by one. Fixes: ae0222b ('powerpc/crypto: nx driver code supporting nx encryption') Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> staging: comedi: daqboard2000: bug fix board type matching code commit 80e162ee9b31d77d851b10f8c5299132be1e120f upstream. `daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the PCI device's subvendor ID to this fixed value. Correct it. Fixes: 7e8401b ("staging: comedi: daqboard2000: add back subsystem_device check") Signed-off-by: Ian Abbott <[email protected]> Cc: <[email protected]> # 3.7+ Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> ACPI / sysfs: fix error code in get_status() commit f18ebc211e259d4f591e39e74b2aa2de226c9a1d upstream. The problem with ornamental, do-nothing gotos is that they lead to "forgot to set the error code" bugs. We should be returning -EINVAL here but we don't. It leads to an uninitalized variable in counter_show(): drivers/acpi/sysfs.c:603 counter_show() error: uninitialized symbol 'status'. Fixes: 1c8fce2 (ACPI: introduce drivers/acpi/sysfs.c) Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED commit ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 upstream. pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were introduced to locklessy (but atomically) detect when a pmd is a regular (stable) pmd or when the pmd is unstable and can infinitely transition from pmd_none() and pmd_trans_huge() from under us, while only holding the mmap_sem for reading (for writing not). While holding the mmap_sem only for reading, MADV_DONTNEED can run from under us and so before we can assume the pmd to be a regular stable pmd we need to compare it against pmd_none() and pmd_trans_huge() in an atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a tiny window for a race. Useful applications are unlikely to notice the difference as doing MADV_DONTNEED concurrently with a page fault would lead to undefined behavior. [js] 3.12 backport: no pmd_devmap in 3.12 yet. [[email protected]: tidy up comment grammar/layout] Signed-off-by: Andrea Arcangeli <[email protected]> Reported-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> MIPS: KVM: Check for pfn noslot case commit ba913e4f72fc9cfd03dad968dfb110eb49211d80 upstream. When mapping a page into the guest we error check using is_error_pfn(), however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an error HVA for the page. This can only happen on MIPS right now due to unusual memslot management (e.g. being moved / removed / resized), or with an Enhanced Virtual Memory (EVA) configuration where the default KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed in a later patch). This case will be treated as a pfn of zero, mapping the first page of physical memory into the guest. It would appear the MIPS KVM port wasn't updated prior to being merged (in v3.10) to take commit 81c52c5 ("KVM: do not treat noslot pfn as a error pfn") into account (merged v3.8), which converted a bunch of is_error_pfn() calls to is_error_noslot_pfn(). Switch to using is_error_noslot_pfn() instead to catch this case properly. Fixes: 858dd5d ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: "Radim KrÄ�mÃ¡Å�" <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> [[email protected]: Backport to v3.16.y] Signed-off-by: James Hogan <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> security: let security modules use PTRACE_MODE_* with bitmasks commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream. It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by: Jann Horn <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Casey Schaufler <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Morris <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Al Viro <[email protected]> Cc: "Eric W. Biederman" <[email protected]> Cc: Willy Tarreau <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> [wt: no smk_ptrace_mode() in 3.10] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> xen-netback: ref count shared rings ... so that we can make sure the rings are not freed until all SKBs in internal queues are consumed. 1. The VM is receiving packets through bonding + bridge + netback + netfront. 2. For some unknown reason at least one packet remains in the rx queue and is not delivered to the domU immediately by netback. 3. The VM finishes shutting down. 4. The shared ring between dom0 and domU is freed. 5. then xen-netback continues processing the pending requests and tries to put the packet into the now already released shared ring. > XXXlan0: port 9(vif26.0) entered disabled state > BUG: unable to handle kernel paging request at ffffc900108641d8 > IP: [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > PGD 57e20067 PUD 57e21067 PMD 571a7067 PTE 0 > Oops: 0000 [varunpilankar#1] SMP > ... > CPU: 0 PID: 12587 Comm: netback/0 Not tainted 3.10.0-ucs58-amd64 varunpilankar#1 Debian 3.10.11-1.58.201405060908 > Hardware name: FUJITSU PRIMERGY BX620 S6/D3051, BIOS 080015 Rev.3C78.3051 07/22/2011 > task: ffff880004b067c0 ti: ffff8800561ec000 task.ti: ffff8800561ec000 > RIP: e030:[<ffffffffa04147dc>] [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > RSP: e02b:ffff8800561edce8 EFLAGS: 00010202 > RAX: ffffc900104adac0 RBX: ffff8800541e95c0 RCX: ffffc90010864000 > RDX: 000000000000003b RSI: 0000000000000000 RDI: ffff880040014380 > RBP: ffff8800570e6800 R08: 0000000000000000 R09: ffff880004799800 > R10: ffffffff813ca115 R11: ffff88005e4fdb08 R12: ffff880054e6f800 > R13: ffff8800561edd58 R14: ffffc900104a1000 R15: 0000000000000000 > FS: 00007f19a54a8700(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffffc900108641d8 CR3: 0000000054cb3000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Stack: > ffff880004b06ba0 0000000000000000 ffff88005da13ec0 ffff88005da13ec0 > 0000000004b067c0 ffffc900104a8ac0 ffffc900104a1020 000000005da13ec0 > 0000000000000000 0000000000000001 ffffc900104a8ac0 ffffc900104adac0 > Call Trace: > [<ffffffff813ca32d>] ? _raw_spin_lock_irqsave+0x11/0x2f > [<ffffffffa0416033>] ? xen_netbk_kthread+0x174/0x841 [xen_netback] > [<ffffffff8105d373>] ? wake_up_bit+0x20/0x20 > [<ffffffffa0415ebf>] ? xen_netbk_tx_build_gops+0xce8/0xce8 [xen_netback] > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > [<ffffffffa0415ebf>] ? xen_netbk_tx_build_gops+0xce8/0xce8 [xen_netback] > [<ffffffff8105ce1e>] ? kthread+0xab/0xb3 > [<ffffffff81003638>] ? xen_end_context_switch+0xe/0x1c > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > [<ffffffff813cfbfc>] ? ret_from_fork+0x7c/0xb0 > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > Code: 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 02 89 70 08 eb 07 c7 40 08 00 00 00 00 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 89 30 c7 44 24 60 00 00 00 00 8b 44 d1 04 89 44 24 > RIP [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > RSP <ffff8800561edce8> > CR2: ffffc900108641d8 Track the shared ring buffer being unmapped and drop those packets. Ref-count the rings as followed: map -> set to 1 start_xmit -> inc when queueing SKB to internal queue rx_action -> dec after finishing processing a SKB unmap -> dec and wait to be 0 Note that this is different from ref counting the vif structure itself. Currently only guest Rx path is taken care of because that's where the bug surfaced. This bug doesn't exist in kernel >=3.12 as multi-queue support was added there. Link: <https://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00818.html> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Philipp Hahn <[email protected]> Cc: David Vrabel <[email protected]> Tested-by: Philipp Hahn <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Shoaib0597 <[email protected]> Linux 3.10.104 Signed-off-by: Shoaib0597 <[email protected]>

commit b6b1b81b3afba922505b57f4c812bba022f7c4a9 upstream. BugLink: http://bugs.launchpad.net/bugs/1268727 The task field in the lsm_audit struct needs to be initialized if a change_hat fails, otherwise the following oops will occur BUG: unable to handle kernel paging request at 0000002fbead7d08 IP: [<ffffffff8171153e>] _raw_spin_lock+0xe/0x50 PGD 1e3f35067 PUD 0 Oops: 0002 [varunpilankar#1] SMP Modules linked in: pppox crc_ccitt p8023 p8022 psnap llc ax25 btrfs raid6_pq xor xfs libcrc32c dm_multipath scsi_dh kvm_amd dcdbas kvm microcode amd64_edac_mod joydev edac_core psmouse edac_mce_amd serio_raw k10temp sp5100_tco i2c_piix4 ipmi_si ipmi_msghandler acpi_power_meter mac_hid lp parport hid_generic usbhid hid pata_acpi mpt2sas ahci raid_class pata_atiixp bnx2 libahci scsi_transport_sas [last unloaded: tipc] CPU: 2 PID: 699 Comm: changehat_twice Tainted: GF O 3.13.0-7-generic #25-Ubuntu Hardware name: Dell Inc. PowerEdge R415/08WNM9, BIOS 1.8.6 12/06/2011 task: ffff8802135c6000 ti: ffff880212986000 task.ti: ffff880212986000 RIP: 0010:[<ffffffff8171153e>] [<ffffffff8171153e>] _raw_spin_lock+0xe/0x50 RSP: 0018:ffff880212987b68 EFLAGS: 00010006 RAX: 0000000000020000 RBX: 0000002fbead7500 RCX: 0000000000000000 RDX: 0000000000000292 RSI: ffff880212987ba8 RDI: 0000002fbead7d08 RBP: ffff880212987b68 R08: 0000000000000246 R09: ffff880216e572a0 R10: ffffffff815fd677 R11: ffffea0008469580 R12: ffffffff8130966f R13: ffff880212987ba8 R14: 0000002fbead7d08 R15: ffff8800d8c6b830 FS: 00002b5e6c84e7c0(0000) GS:ffff880216e40000(0000) knlGS:0000000055731700 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000002fbead7d08 CR3: 000000021270f000 CR4: 00000000000006e0 Stack: ffff880212987b98 ffffffff81075f17 ffffffff8130966f 0000000000000009 0000000000000000 0000000000000000 ffff880212987bd0 ffffffff81075f7c 0000000000000292 ffff880212987c08 ffff8800d8c6b800 0000000000000026 Call Trace: [<ffffffff81075f17>] __lock_task_sighand+0x47/0x80 [<ffffffff8130966f>] ? apparmor_cred_prepare+0x2f/0x50 [<ffffffff81075f7c>] do_send_sig_info+0x2c/0x80 [<ffffffff81075fee>] send_sig_info+0x1e/0x30 [<ffffffff8130242d>] aa_audit+0x13d/0x190 [<ffffffff8130c1dc>] aa_audit_file+0xbc/0x130 [<ffffffff8130966f>] ? apparmor_cred_prepare+0x2f/0x50 [<ffffffff81304cc2>] aa_change_hat+0x202/0x530 [<ffffffff81308fc6>] aa_setprocattr_changehat+0x116/0x1d0 [<ffffffff8130a11d>] apparmor_setprocattr+0x25d/0x300 [<ffffffff812cee56>] security_setprocattr+0x16/0x20 [<ffffffff8121fc87>] proc_pid_attr_write+0x107/0x130 [<ffffffff811b7604>] vfs_write+0xb4/0x1f0 [<ffffffff811b8039>] SyS_write+0x49/0xa0 [<ffffffff8171a1bf>] tracesys+0xe1/0xe6 Signed-off-by: John Johansen <[email protected]> Acked-by: Seth Arnold <[email protected]> Acked-by: Jeff Mahoney <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Willy Tarreau <[email protected]>

If a user key gets negatively instantiated, an error code is cached in the payload area. A negatively instantiated key may be then be positively instantiated by updating it with valid data. However, the ->update key type method must be aware that the error code may be there. The following may be used to trigger the bug in the user key type: keyctl request2 user user "" @U keyctl add user user "a" @U which manifests itself as: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 PGD 7cc30067 PUD 0 Oops: 0002 [varunpilankar#1] SMP Modules linked in: CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000 RIP: 0010:[<ffffffff810a376f>] [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246 RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001 RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82 RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82 R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700 FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0 Stack: ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620 Call Trace: [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129 [< inline >] __key_update security/keys/key.c:730 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908 [< inline >] SYSC_add_key security/keys/keyctl.c:125 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185 Note the error code (-ENOKEY) in EDX. A similar bug can be tripped by: keyctl request2 trusted user "" @U keyctl add trusted user "a" @U This should also affect encrypted keys - but that has to be correctly parameterised or it will fail with EINVAL before getting to the bit that will crashes. Change-Id: I6452091ee01e324c934cf0c7d5a0f3ffa5d0b001 Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Mimi Zohar <[email protected]> Signed-off-by: James Morris <[email protected]>

Protocol sockets (struct sock) don't have UIDs, but most of the time, they map 1:1 to userspace sockets (struct socket) which do. Various operations such as the iptables xt_owner match need access to the "UID of a socket", and do so by following the backpointer to the struct socket. This involves taking sk_callback_lock and doesn't work when there is no socket because userspace has already called close(). Simplify this by adding a sk_uid field to struct sock whose value matches the UID of the corresponding struct socket. The semantics are as follows: 1. Whenever sk_socket is non-null: sk_uid is the same as the UID in sk_socket, i.e., matches the return value of sock_i_uid. Specifically, the UID is set when userspace calls socket(), fchown(), or accept(). 2. When sk_socket is NULL, sk_uid is defined as follows: - For a socket that no longer has a sk_socket because userspace has called close(): the previous UID. - For a cloned socket (e.g., an incoming connection that is established but on which userspace has not yet called accept): the UID of the socket it was cloned from. - For a socket that has never had an sk_socket: UID 0 inside the user namespace corresponding to the network namespace the socket belongs to. Kernel sockets created by sock_create_kern are a special case of varunpilankar#1 and sk_uid is the user that created them. For kernel sockets created at network namespace creation time, such as the per-processor ICMP and TCP sockets, this is the user that created the network namespace. [Backport of net-next 86741ec25462e4c8cdce6df2f41ead05568c7d5e] Bug: 16355602 Change-Id: Idbc3e9a0cec91c4c6e01916b967b6237645ebe59 Signed-off-by: Lorenzo Colitti <[email protected]> Signed-off-by: David S. Miller <[email protected]>

…kernel_cyanogen_msm8916

…android_kernel_cyanogen_msm8916" This reverts commit 6dffb35, reversing changes made to 8b9203f.

…kernel_cyanogen_msm8916

Arun Kumar Neelakantam and others added 30 commits September 28, 2016 22:05

ASoC: msm: Add Buffer overflow check

50ce387

The overflow check is required to ensure that user space data in kernel may not go beyond buffer boundary CRs-Fixed: 1064411 Change-Id: I54c28a8942cf1a6a47a4e8272f3159b35d753ead Signed-off-by: Karthik Reddy Katta <[email protected]>

ASoC: utils: initialize dummy_codec before use

fe8ca7a

dummy_codec is not initialized before use, which could cause kernel panic. Initialize dummy_codec before use. Change-Id: Iedf7a3accbd14138ab7ed9e4e36a98fd7ca9a839 Signed-off-by: Meng Wang <[email protected]>

Merge "ASoC: msm: qdsp6v2: check param length for EAC3 format"

dbd6cc9

Merge "ASoC: utils: initialize dummy_codec before use"

5ccd0d0

Merge "qcedev: Validate Source and Destination addresses"

7f7eb5a

Merge "ASoC: msm: initialize the params array before using it"

0d05502

Merge "ARM: dts: msm: Route to sw crypto for hmac and aead on msm8939"

619513c

Merge "Don't show empty tag stats for unprivileged uids"

d8e24d4

Merge "msm: sensor: validate the i2c table index before use"

031fac1

Merge "input: synaptics_dsx: allocate heap memory for temp buf"

6fbce21

Merge AU_LINUX_ANDROID_LA.BR.1.2.6_RB1.06.00.01.179.026 on remote branch

e80fe0e

Change-Id: I74875bd7ad075e1e77dd82132be191e53e1eda02

ARM: dts: ql790: update for HQ kionix accel sensor

7cc7cc7

Change-Id: Ia7660b0b3026ffa93e57338501d834e7766a9af3

Srinivasarao P and others added 10 commits January 1, 2018 08:17

Revert "SELinux: use deletion-safe iterator to free list"

61dc528

This reverts commit e623b152f30f6f1204919315df37244d69e5d55e. Change-Id: I8e8903786da86cbe4206c18f817fbb54db229472 Signed-off-by: Aravind Asam <[email protected]>

Revert "SELinux: per-command whitelisting of ioctls"

d7cd4c3

This reverts commit ba733f9857b966459316d0cd33b8da2e22f62d7d. Change-Id: Ie4d3e904160195dafd93a59a25d56b1449e8fc86 Signed-off-by: Aravind Asam <[email protected]>

eparis and others added 10 commits January 2, 2018 16:55

security: add PFT to the default security LSM list

ad61e81

Allow selecting PFT as the chosen LSM (Linux Security Module). Change-Id: I45f403535e72cf9374b0d8c0263f6f64e4d710e6 Signed-off-by: Amir Samuelov <[email protected]>

Merge "security: add PFT to the default security LSM list"

3372651

AndroiableDroid added 3 commits January 26, 2018 11:56

Merge branch 'cm-13.0' of https://github.com/AndroiableDroid/android_…

6dffb35

…kernel_cyanogen_msm8916

Revert "Merge branch 'cm-13.0' of https://github.com/AndroiableDroid/…

91faa4a

…android_kernel_cyanogen_msm8916" This reverts commit 6dffb35, reversing changes made to 8b9203f.

Merge branch 'cm-14.0' of https://github.com/AndroiableDroid/android_…

bd269fe

…kernel_cyanogen_msm8916

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge #1

Merge #1

AndroiableDroid commented Dec 15, 2017

Merge #1

Are you sure you want to change the base?

Merge #1

Conversation

AndroiableDroid commented Dec 15, 2017