aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'cm-14.1' of ↵HEADn7.1Suraj Das2017-06-2574-343/+664
|\ | | | | | | https://github.com/LineageOS/android_kernel_oneplus_msm8974 into n7.1
| * prima: Fix array out-of-bounds & integer underflow in _iw_set_genieSrinivas Girigowda2017-06-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | 'wrqu->data.length' holds the total number of IE data buffer. Add a check to make sure the number of remaining data to be read is greater than or equal to IE length. Also, advance the buffer pointer to point to the next element only if next element is present. Change-Id: Ic60f3e0650f365955dab4099eb8740e9789e00cc CRs-Fixed: 1100132
| * prima: Add buf len check in wlan_hdd_cfg80211_testmodeManjeet Singh2017-06-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | In __wlan_hdd_cfg80211_testmode API no checks are in place that ensure that buflen is smaller or equal the size of the stack variable hb_params. Hence, the vos_mem_copy() call can overflow stack memory. Add buf len check to avoid stack overflow CRs-Fixed: 1105085 Change-Id: I6af6a74cc38ebce3337120adcf7e9595f22d3d8c
| * prima: Avoid overflow of "significant change" paramsJeff Johnson2017-06-141-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wlan driver supports the following vendor command: QCA_NL80211_VENDOR_SUBCMD_EXTSCAN_SET_SIGNIFICANT_CHANGE This command supplies a "number of APs" attribute as well as a list of per-AP attributes. However there is no validation that the number of APs provided won't overflow the destination buffer. In addition there is no validation that the number of APs actually provided matches the number of APs expected. To address these issues: * Verify that the expected number of APs doesn't exceed the maximum allowed number of APs * Verify that the actual number of APs supplied doesn't exceed the expected number of APs * Only process the actual number of supplied APs if it is less than the expected number of APs. Change-Id: I0513ffbc4a38f1d7ddbc0815d3618fc9a2ea4f77 CRs-Fixed: 1095009
| * prima: Avoid overflow of "set_bssid_hotlist" paramsHanumanth Reddy Pothula2017-06-141-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wlan driver supports the following vendor command: QCA_NL80211_VENDOR_SUBCMD_EXTSCAN_SET_BSSID_HOTLIST This command supplies a "number of APs" attribute as well as a list of per-AP attributes. However there is no validation that the number of APs provided won't overflow the destination buffer. In addition there is no validation that the number of APs actually provided matches the number of APs expected. To address these issues: * Verify that the expected number of APs doesn't exceed the maximum allowed number of APs * Verify that the actual number of APs supplied doesn't exceed the expected number of APs * Only process the actual number of supplied APs if it is less than the expected number of APs. Change-Id: I41e36d11bc3e71928866a27afc2fbf046b59f0f5 CRs-Fixed: 1095770
| * fs/proc/array.c: make safe access to group_leaderAdrian Salido2017-06-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in commit 52ee2dfdd4f51cf422ea6a96a0846dc94244aa37 ("pids: refactor vnr/nr_ns helpers to make them safe"). *_nr_ns helpers used to be buggy. The commit addresses most of the helpers but is missing task_tgid_xxx() Without this protection there is a possible use after free reported by kasan instrumented kernel: ================================================================== BUG: KASAN: use-after-free in task_tgid_nr_ns+0x2c/0x44 at addr *** Read of size 8 by task cat/2472 CPU: 1 PID: 2472 Comm: cat Tainted: **** Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc00020ad2c>] dump_backtrace+0x0/0x17c [<ffffffc00020aec0>] show_stack+0x18/0x24 [<ffffffc0011573d0>] dump_stack+0x94/0x100 [<ffffffc0003c7dc0>] kasan_report+0x308/0x554 [<ffffffc0003c7518>] __asan_load8+0x20/0x7c [<ffffffc00025a54c>] task_tgid_nr_ns+0x28/0x44 [<ffffffc00046951c>] proc_pid_status+0x444/0x1080 [<ffffffc000460f60>] proc_single_show+0x8c/0xdc [<ffffffc0004081b0>] seq_read+0x2e8/0x6f0 [<ffffffc0003d1420>] vfs_read+0xd8/0x1e0 [<ffffffc0003d1b98>] SyS_read+0x68/0xd4 Accessing group_leader while holding rcu_lock and using the now safe helpers introduced in the commit mentioned, this race condition is addressed. Signed-off-by: Adrian Salido <salidoa@google.com> Change-Id: I4315217922dda375a30a3581c0c1740dda7b531b Bug: 31495866
| * prima: Use heap memory for station_info instead of stackkaliu2017-06-142-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | From kernel 3.19-rc4, size of struct station_info is around 600 bytes, so stack frame size of such routine use this struct will easily exceed 1024 bytes, the default value of stack frame size. So use heap memory for this struct instead. Change-Id: Ibe8a4f5189fcc9d5554f7a5d851c93be8fa8dbad CRs-Fixed: 1050323 [GabrieleM: port from qcacld-2.0 to prima]
| * tmpfs: clear S_ISGID when setting posix ACLsGu Zheng2017-06-141-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change was missed the tmpfs modification in In CVE-2016-7097 commit 073931017b49 ("posix_acl: Clear SGID bit when setting file permissions") It can test by xfstest generic/375, which failed to clear setgid bit in the following test case on tmpfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Change-Id: I639fb4221e65b8c1ab3cc26ba735521e25967faa Signed-off-by: Gu Zheng <guzheng1@huawei.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> [gmrt: Backport to 3.4]
| * BACKPORT: posix_acl: Clear SGID bit when setting file permissionsJan Kara2017-06-1415-103/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Partially applied during f2fs inclusion, changes now aligned to upstream] (cherry pick from commit 073931017b49d9458aa351605b43a7e34598caef) When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. NB: conflicts resolution included extending the change to all visible users of the near deprecated function posix_acl_equiv_mode replaced with posix_acl_update_mode. We did not resolve the ACL leak in this CL, require additional upstream fixes. References: CVE-2016-7097 Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Bug: 32458736 [haggertk]: Backport to 3.4/msm8974 * convert use of capable_wrt_inode_uidgid to capable Change-Id: I19591ad452cc825ac282b3cfd2daaa72aa9a1ac1
| * cgroup: prefer %pK to %pNick Desaulniers2017-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | Prevents leaking kernel pointers when using kptr_restrict. Bug: 30149174 Change-Id: I0fa3cd8d4a0d9ea76d085bba6020f1eda073c09b Git-repo: https://android.googlesource.com/kernel/msm.git Git-commit: 505e48f32f1321ed7cf80d49dd5f31b16da445a8 Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
| * ASoC: msm: initialize the params array before using itvivek mehta2017-06-141-0/+2
| | | | | | | | | | | | | | | | | | The params array is used without initialization, which may cause security issues. Initialize it as all zero after the definition. bug: 30902162 Change-Id: If462fe3d82f139d72547f82dc7eb564f83cb35bf Signed-off-by: vivek mehta <mvivek@codeaurora.org>
| * msm: vidc: use %pK instead of %p which respects kptr_restrict sysctlAbdulla Anam2017-06-149-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | Hide kernel pointers from unprivileged ussers by using %pK format- specifier instead of %p. This respects the kptr_restrict sysctl setting which is by default on. So by default %pK will print zeroes as address. echo 1 to kptr_restrict to print proper kernel addresses. CRs-Fixed: 987018 Change-Id: I4772257a557c6730ecc0624cbc8e5614e893e9fd Signed-off-by: Abdulla Anam <abdullahanam@codeaurora.org> Signed-off-by: Bikshapathi Kothapeta <bkotha@codeaurora.org>
| * qseecom: Change format specifier %p to %pKMallikarjuna Reddy Amireddy2017-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's. So that %pK will not leak kernel pointers to unprivileged users. So change the format specifier from %p to %pK. Debugging Note : &pK prints only Zeros as address. if you need actual address information, pls echo 0 to kptr_restrict. $ echo 0 > /proc/sys/kernel/kptr_restrict Bug: 31498159 Change-Id: I0baf2be2d5a476e2e4267f20b99d0ddf5492469e Signed-off-by: Mallikarjuna Reddy Amireddy <mamire@codeaurora.org>
| * ASoC: soc: msm: initialize buffer to prevent kernel data leakageXiaojun Sang2017-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To prevent potential kernel stack data leakage, initialize channel_map[]. CRs-Fixed: 1100878 CAF-Change-Id: I7b81cea20485bc7514551672bb54c7fd455049e3 Signed-off-by: Xiaojun Sang <xsang@codeaurora.org> CVE-2016-5347 [haggertk]: Backport to 3.4/msm8974 * Same logic in our msm-pcm-routing-v2.c as opposed to original msm-qti-pp-config.c Change-Id: Iea0b630d1785e03d16da2d4f651846ab06d73e23
| * USB: cypress_m8: add endpoint sanity checkOliver Neukum2017-06-141-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | An attack using missing endpoints exists. CVE-2016-3137 Change-Id: Ic4fa75a7133dd7b66c91622dec84776c08ae21c3 Signed-off-by: Oliver Neukum <ONeukum@suse.com> CC: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * slim-msm: Synchronize SSR callbacksDilip Kota2017-06-142-0/+6
| | | | | | | | | | | | | | | | | | | | Subsystem will restart within short timeframe. Synchronise subsytem up/down callback notifications to avoid functionality failures. Use mutex locks to achieve synchronization. Change-Id: I5881c7d468507bb8402a2e9f8178b9c31e57e8a5 Signed-off-by: Dilip Kota <dkota@codeaurora.org>
| * crypto: msm: check length before copying to buf in _debug_stats_readZhen Kong2017-06-143-6/+6
| | | | | | | | | | | | | | | | Make sure that `len` is not larger than `count` before copying data to userspace `buf` in _debug_stats_read(). Change-Id: Iafb7cfa3828653f8c28183c812797c3d9a183da1 Signed-off-by: Zhen Kong <zkong@codeaurora.org>
| * prima: Trim operation classes to max supported in change stationSaidiReddy Yenuga2017-06-141-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Operation classes supported can be controlled by user, which can be sent greater than the max supported operations. This results in stack overflow in change station command. Add check to validate operations supported param given by user and if it exceeds max supported value, set it to max supported value. CRs-Fixed: 2002052 Change-Id: Idd3a35e38b091546a17d7ec6329f19429e5c289c
| * ASoC: wcd9320: Fix out of bounds for mad input valueKarthikeyan Mani2017-06-121-0/+8
| | | | | | | | | | | | | | | | | | | | Add check in taiko_mad_input_put function to return error on out of bounds access using mad input value CRs-fixed: 1096799 Change-Id: I75ce9e881cf05a50e874a555b2f8bd3286cdaed4 Signed-off-by: Karthikeyan Mani <kmani@codeaurora.org>
| * udp: properly support MSG_PEEK with truncated buffersEric Dumazet2017-06-122-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 197c949e7798fbf28cfadc69d9ca0c2abbf93191 upstream. Backport of this upstream commit into stable kernels : 89c22d8c3b27 ("net: Fix skb csum races when peeking") exposed a bug in udp stack vs MSG_PEEK support, when user provides a buffer smaller than skb payload. In this case, skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr), msg->msg_iov); returns -EFAULT. This bug does not happen in upstream kernels since Al Viro did a great job to replace this into : skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg); This variant is safe vs short buffers. For the time being, instead reverting Herbert Xu patch and add back skb->ip_summed invalid changes, simply store the result of udp_lib_checksum_complete() so that we avoid computing the checksum a second time, and avoid the problematic skb_copy_and_csum_datagram_iovec() call. This patch can be applied on recent kernels as it avoids a double checksumming, then backported to stable kernels as a bug fix. Change-Id: I31690126a6e353ab91ec80e7c071532a6d2ae1a5 Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> Fixes: CVE-2016-10229 Signed-off-by: Joel Stanley <joel@jms.id.au>
| * perf: Tighten (and fix) the grouping conditionPeter Zijlstra2017-06-122-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Fixes: 9fc81d87420d ("perf: Fix events installation during moving group") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org> CVE-2015-9004 Change-Id: I598c380f40384c3dfee6099c381bbc17fe924e68
| * libceph: introduce ceph_crypt() for in-place en/decryptionIlya Dryomov2017-05-232-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with 4.9, kernel stacks may be vmalloced and therefore not guaranteed to be physically contiguous; the new CONFIG_VMAP_STACK option is enabled by default on x86. This makes it invalid to use on-stack buffers with the crypto scatterlist API, as sg_set_buf() expects a logical address and won't work with vmalloced addresses. There isn't a different (e.g. kvec-based) crypto API we could switch net/ceph/crypto.c to and the current scatterlist.h API isn't getting updated to accommodate this use case. Allocating a new header and padding for each operation is a non-starter, so do the en/decryption in-place on a single pre-assembled (header + data + padding) heap buffer. This is explicitly supported by the crypto API: "... the caller may provide the same scatter/gather list for the plaintext and cipher text. After the completion of the cipher operation, the plaintext data is replaced with the ciphertext data in case of an encryption and vice versa for a decryption." Change-Id: I554cae76340899bb6f00e2e06230f3a27da186a1 Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
| * ecryptfs: don't allow mmap when the lower fs doesn't support itJeff Mahoney2017-05-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively. CVE-2016-1583 Signed-off-by: Jeff Mahoney <jeffm@suse.com> Cc: stable@vger.kernel.org [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()] Signed-off-by: Tyler Hicks <tyhicks@canonical.com> (adapted from commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b) Change-Id: I3eb979e9476847834eeea0ecbaf07a53329a7219
| * kernel: Fix potential refcount leak in su checkTom Marshall2017-05-191-1/+3
| | | | | | | | Change-Id: I3d241ae805ba708c18bccfd5e5d6cdcc8a5bc1c8
| * kernel: Only expose su when daemon is runningTom Marshall2017-05-118-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It has been claimed that the PG implementation of 'su' has security vulnerabilities even when disabled. Unfortunately, the people that find these vulnerabilities often like to keep them private so they can profit from exploits while leaving users exposed to malicious hackers. In order to reduce the attack surface for vulnerabilites, it is therefore necessary to make 'su' completely inaccessible when it is not in use (except by the root and system users). Change-Id: Ia7d50ba46c3d932c2b0ca5fc8e9ec69ec9045f85
| * sdcardfs: limit stacking depthAndrew Chant2017-05-021-0/+7
| | | | | | | | | | | | | | | | | | Limit filesystem stacking to prevent stack overflow. Bug: 32761463 Change-Id: I8b1462b9c0d6c7f00cf110724ffb17e7f307c51e Signed-off-by: Andrew Chant <achant@google.com> CVE-2014-9922
| * BACKPORT: fs: limit filesystem stacking depthMiklos Szeredi2017-05-022-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a simple read-only counter to super_block that indicates how deep this is in the stack of filesystems. Previously ecryptfs was the only stackable filesystem and it explicitly disallowed multiple layers of itself. Overlayfs, however, can be stacked recursively and also may be stacked on top of ecryptfs or vice versa. To limit the kernel stack usage we must limit the depth of the filesystem stack. Initially the limit is set to 2. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> (cherry picked from commit 69c433ed2ecd2d3264efd7afec4439524b319121) Bug: 32761463 Change-Id: I69b2fba2112db2ece09a1bf61a44f8fc4db00820 CVE-2014-9922
| * crypto: msm: check integer overflow on total data len in qcedev.cZhen Kong2017-05-021-1/+10
| | | | | | | | | | | | | | | | | | | | qcedev_vbuf_ablk_cipher will calculate total data length. It starts with the value of "areq->cipher_op_req.byteoffset", which is controlled by the user. Make change to check if this total data length has integer overflow issue in qcedev_check_cipher_params. Change-Id: Ice42dca6d47eb8febfe8a34e566c69e4799fab57 Signed-off-by: Zhen Kong <zkong@codeaurora.org>
| * msm: crypto: fix issues on digest buf and copy_from_user in qcedev.cZhen Kong2017-05-021-93/+27
| | | | | | | | | | | | | | | | | | | | Make the digest length not larger than the size of the buffer qcedev_areq.sha_op_req.digest; and use the checked variants of the copy_from/to_user() APIs to avoid small race window of their unchecked variants. Change-Id: I3db0c20ac5fa47ed278f3d60368c406f472430c1 Signed-off-by: Zhen Kong <zkong@codeaurora.org>
| * KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyringsEric Biggers2017-05-022-24/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream. This fixes CVE-2017-7472. Running the following program as an unprivileged user exhausts kernel memory by leaking thread keyrings: #include <keyutils.h> int main() { for (;;) keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING); } Fix it by only creating a new thread keyring if there wasn't one before. To make things more consistent, make install_thread_keyring_to_cred() and install_process_keyring_to_cred() both return 0 if the corresponding keyring is already present. Change-Id: I584b867ac876b8040254a2e9d8ac3948413d7c5a Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * KEYS: Change the name of the dead type to ".dead" to prevent user accessDavid Howells2017-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream. This fixes CVE-2017-6951. Userspace should not be able to do things with the "dead" key type as it doesn't have some of the helper functions set upon it that the kernel needs. Attempting to use it may cause the kernel to crash. Fix this by changing the name of the type to ".dead" so that it's rejected up front on userspace syscalls by key_get_type_from_user(). Though this doesn't seem to affect recent kernels, it does affect older ones, certainly those prior to: commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81 Author: David Howells <dhowells@redhat.com> Date: Tue Sep 16 17:36:06 2014 +0100 KEYS: Remove key_type::match in favour of overriding default by match_preparse which went in before 3.18-rc1. Change-Id: Ie0fe24b5c5f341c152e511976b60d393056e89fb Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * KEYS: Disallow keyrings beginning with '.' to be joined as session keyringsDavid Howells2017-05-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream. This fixes CVE-2016-9604. Keyrings whose name begin with a '.' are special internal keyrings and so userspace isn't allowed to create keyrings by this name to prevent shadowing. However, the patch that added the guard didn't fix KEYCTL_JOIN_SESSION_KEYRING. Not only can that create dot-named keyrings, it can also subscribe to them as a session keyring if they grant SEARCH permission to the user. This, for example, allows a root process to set .builtin_trusted_keys as its session keyring, at which point it has full access because now the possessor permissions are added. This permits root to add extra public keys, thereby bypassing module verification. This also affects kexec and IMA. This can be tested by (as root): keyctl session .builtin_trusted_keys keyctl add user a a @s keyctl list @s which on my test box gives me: 2 keys in keyring: 180010936: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05 801382539: --alswrv 0 0 user: a Fix this by rejecting names beginning with a '.' in the keyctl. Change-Id: I9bb919f82b62c3cf0d7dcbad9b551b8fe7d934ae Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com> cc: linux-ima-devel@lists.sourceforge.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * mm: migrate dirty page without clear_page_dirty_for_io etcHugh Dickins2017-05-021-20/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 42cb14b110a5698ccf26ce59c4441722605a3743 upstream. clear_page_dirty_for_io() has accumulated writeback and memcg subtleties since v2.6.16 first introduced page migration; and the set_page_dirty() which completed its migration of PageDirty, later had to be moderated to __set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too. No actual problems seen with this procedure recently, but if you look into what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually achieving, it turns out to be nothing more than moving the PageDirty flag, and its NR_FILE_DIRTY stat from one zone to another. It would be good to avoid a pile of irrelevant decrementations and incrementations, and improper event counting, and unnecessary descent of the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which radix_tree_replace_slot() left in place anyway). Do the NR_FILE_DIRTY movement, like the other stats movements, while interrupts still disabled in migrate_page_move_mapping(); and don't even bother if the zone is the same. Do the PageDirty movement there under tree_lock too, where old page is frozen and newpage not yet visible: bearing in mind that as soon as newpage becomes visible in radix_tree, an un-page-locked set_page_dirty() might interfere (or perhaps that's just not possible: anything doing so should already hold an additional reference to the old page, preventing its migration; but play safe). But we do still need to transfer PageDirty in migrate_page_copy(), for those who don't go the mapping route through migrate_page_move_mapping(). CVE-2016-3070 Signed-off-by: Hugh Dickins <hughd@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [ciwillia@brocade.com: backported to 3.10: adjusted context] Signed-off-by: Charles (Chas) Williams <ciwillia@brocade.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Change-Id: Ifee7c4f76e277763ef2dd63c810590cd237575a4
| * mm: fix warning in __set_page_dirty_nobuffersHugh Dickins2017-05-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New tmpfs use of !PageUptodate pages for fallocate() is triggering the WARNING: at mm/page-writeback.c:1990 when __set_page_dirty_nobuffers() is called from migrate_page_copy() for compaction. It is anomalous that migration should use __set_page_dirty_nobuffers() on an address_space that does not participate in dirty and writeback accounting; and this has also been observed to insert surprising dirty tags into a tmpfs radix_tree, despite tmpfs not using tags at all. We should probably give migrate_page_copy() a better way to preserve the tag and migrate accounting info, when mapping_cap_account_dirty(). But that needs some more work: so in the interim, avoid the warning by using a simple SetPageDirty on PageSwapBacked pages. Change-Id: I3cc9b67912e3aaaf6849a6681c48d17756575c7e Reported-and-tested-by: Dave Jones <davej@redhat.com> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * mm/mempolicy.c: fix error handling in set_mempolicy and mbind.Chris Salls2017-05-021-12/+8
| | | | | | | | | | | | | | | | | | | | In the case that compat_get_bitmap fails we do not want to copy the bitmap to the user as it will contain uninitialized stack data and leak sensitive data. Change-Id: I188fb5950c9804bd79ef959973108a8519bf04bb Signed-off-by: Chris Salls <salls@cs.ucsb.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * net/packet: fix overflow in check for tp_frame_nrAndrey Konovalov2017-05-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When calculating rb->frames_per_block * req->tp_block_nr the result can overflow. Add a check that tp_block_size * tp_block_nr <= UINT_MAX. Since frames_per_block <= tp_block_size, the expression would never overflow. Change-Id: I3598423e621275aa1d890b80bcf9018929087d90 Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Acked-by: Eric Dumazet <edumazet@google.com>
| * net/packet: fix overflow in check for tp_reserveAndrey Konovalov2017-05-021-0/+2
| | | | | | | | | | | | | | | | | | | | When calculating po->tp_hdrlen + po->tp_reserve the result can overflow. Fix by checking that tp_reserve <= INT_MAX on assign. Change-Id: I6a4ea0cbe87cfd3db0979896c9bf9b3c626ec1d6 Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Acked-by: Eric Dumazet <edumazet@google.com>
| * scsi: sg: check length passed to SG_NEXT_CMD_LENpeter chang2017-05-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The user can control the size of the next command passed along, but the value passed to the ioctl isn't checked against the usable max command size. Change-Id: I9e8eb8ca058c0103a22f5d99d77919432893aa4c Cc: <stable@vger.kernel.org> Signed-off-by: Peter Chang <dpf@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * sg: relax 16 byte cdb restrictionDouglas Gilbert2017-05-022-84/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - remove the 16 byte CDB (SCSI command) length limit from the sg driver by handling longer CDBs the same way as the bsg driver. Remove comment from sg.h public interface about the cmd_len field being limited to 16 bytes. - remove some dead code caused by this change - cleanup comment block at the top of sg.h, fix urls Change-Id: Ie8150e5375b3316d5d5206f079c4a50f1c50b755 Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * block: add blk_rq_set_block_pc()Jens Axboe2017-05-0217-20/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the optimizations around not clearing the full request at alloc time, we are leaving some of the needed init for REQ_TYPE_BLOCK_PC up to the user allocating the request. Add a blk_rq_set_block_pc() that sets the command type to REQ_TYPE_BLOCK_PC, and properly initializes the members associated with this type of request. Update callers to use this function instead of manipulating rq->cmd_type directly. Includes fixes from Christoph Hellwig <hch@lst.de> for my half-assed attempt. Change-Id: Ifc386dfb951c5d6adebf48ff38135dda28e4b1ce Signed-off-by: Jens Axboe <axboe@fb.com>
| * platform: msm: spmi: Fix possible race condition in debugfsansharma2017-05-021-9/+28
| | | | | | | | | | | | | | | | | | There is a possible race condition when debugfs files are concurrently accessed by multiple threads. Fix this. CRs-Fixed: 1106842 Change-Id: Ifd092143f428db3cf73c45ec4f0aaa96318ae165 Signed-off-by: ansharma <ansharma@codeaurora.org>
| * prima: Fix buffer overflow in WLANSAP_Set_WPARSNIes()Nishank Aggarwal2017-05-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently In WLANSAP_Set_WPARSNIes() the parameter WPARSNIEsLen is user-controllable and never validates which uses as the length for a memory copy. This enables user-space applications to corrupt heap memory and potentially crash the kernel. Fix is to validate the WPARSNIes length to its max before use as the length for a memory copy. Change-Id: I7aff731aeae22bfd84beb955439a799abef37f68 CRs-Fixed: 1102648
| * prima: Fix VHT-80 IBSS stops beaconingSubrat Dash2017-05-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | A STA entry is created for each peer joining the network to take care of the peer specific capabilities. The VDEV need not be reconfigured for IBSS peer with different channel width joining the network. Change-Id: Iec6ec5d2b510b84538f4e5300b3f1c5cc63b334d CRs-Fixed: 1046409
| * msm-camera: Addressing possible overflow conditionsTrilokesh Rangam2017-05-021-0/+6
| | | | | | | | | | | | | | | | | | Changes to address possible integer overflow and incorrect array indexing conditions. Change-Id: Ib134320cd6f7b34d7a10572ec347ec12127049a9 Signed-off-by: Trilokesh Rangam <tranga@codeaurora.org> [GabrieleM: Add only NULL check]
| * qcrypto: protect potential integer overflow.Neeraj Soni2017-05-021-0/+6
| | | | | | | | | | | | | | | | | | Adding user passed parameters without check might lead to Integer overflow and unpredictable system behaviour. Change-Id: Iaf8259e3c4a157e1790f1447b1b62a646988b7c4 Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
| * l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()Guillaume Nault2017-05-021-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind(). Without lock, a concurrent call could modify the socket flags between the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way, a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it would then leave a stale pointer there, generating use-after-free errors when walking through the list or modifying adjacent entries. BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8 Write of size 8 by task syz-executor/10987 CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0 Call Trace: [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 [< inline >] print_address_description mm/kasan/report.c:194 [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283 [< inline >] kasan_report mm/kasan/report.c:303 [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329 [< inline >] __write_once_size ./include/linux/compiler.h:249 [< inline >] __hlist_del ./include/linux/list.h:622 [< inline >] hlist_del_init ./include/linux/list.h:637 [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239 [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff813774f9>] task_work_run+0xf9/0x170 [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448 Allocated: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0 [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20 [ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708 [ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716 [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721 [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326 [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388 [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182 [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153 [ 1116.897025] [< inline >] sock_create net/socket.c:1193 [ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223 [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203 [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6 Freed: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0 [ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352 [ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 1116.897025] [< inline >] slab_free mm/slub.c:2951 [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973 [ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369 [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444 [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452 [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460 [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471 [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589 [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243 [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170 [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Memory state around the buggy address: ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table. Change-Id: Ia16e6d18c66672b6d4a8b01de215f9abc0175be3 Fixes: c51ce49735c1 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case") Reported-by: Baozeng Ding <sploving1@gmail.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Baozeng Ding <sploving1@gmail.com> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
| * fix mismerge: packet: fix races in fanout_add()Eric Dumazet2017-05-021-12/+14
| | | | | | | | Change-Id: I68cfd6fcf94d494e2e93f142fb555250331ab13f
* | Cosmetic changesSuraj Das2017-04-052-4/+4
| |
* | wakeup: Expose wakeup_sources via procfs when debugfs isn't presentSultanxda2017-04-031-0/+10
| | | | | | | | | | | | | | Full path: /proc/wakeup/wakeup_sources Signed-off-by: Sultanxda <sultanxda@gmail.com> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* | cpufreq: Make sure target freq is within limitsViresh Kumar2017-04-031-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | __cpufreq_driver_target() must not pass target frequency beyond the limits of current policy. Today most of cpufreq platform drivers are doing this check in their target routines. Why not move it to __cpufreq_driver_target()? Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 00:28:03 +0000