{"push_id":1106582583,"size":68,"distinct_size":45,"ref":"refs/heads/cm-13.0","head":"e9f6757bb86d5b0875373d5f8128dfaba900fd93","before":"b4a11dbaec61eebf3815b26b263b8f64eb50a5bd","commits":[{"sha":"d965aca981b2c5e4a58dcc77aafbf5ccfdf1e751","author":{"email":"942b402b07c522a8271785df04894b4692262f69@openwall.com","name":"Vasily Kulikov"},"message":"include/linux/poison.h: fix LIST_POISON{1,2} offset\n\nPoison pointer values should be small enough to find a room in\nnon-mmap'able/hardly-mmap'able space.  E.g.  on x86 \"poison pointer space\"\nis located starting from 0x0.  Given unprivileged users cannot mmap\nanything below mmap_min_addr, it should be safe to use poison pointers\nlower than mmap_min_addr.\n\nThe current poison pointer values of LIST_POISON{1,2} might be too big for\nmmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu\nuses only 0x10000).  There is little point to use such a big value given\nthe \"poison pointer space\" below 1 MB is not yet exhausted.  Changing it\nto a smaller value solves the problem for small mmap_min_addr setups.\n\nThe values are suggested by Solar Designer:\nhttp://www.openwall.com/lists/oss-security/2015/05/02/6\n\nBug: 26186802\nChange-Id: Ie2121a417b6a43ee6d119c996b5ec2ad6d01a0a7\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/d965aca981b2c5e4a58dcc77aafbf5ccfdf1e751"},{"sha":"2ff841fa89cd66f8291828ea657301630858d3a1","author":{"email":"eec72676ad9a62f2727dfed6d270d98c0d02adec@linux.intel.com","name":"Kirill A. Shutemov"},"message":"BACKPORT: pagemap: do not leak physical addresses to non-privileged userspace\n\n(cherry pick from commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce)\n\nAs pointed by recent post[1] on exploiting DRAM physical imperfection,\n/proc/PID/pagemap exposes sensitive information which can be used to do\nattacks.\n\nThis disallows anybody without CAP_SYS_ADMIN to read the pagemap.\n\n[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html\n\n[ Eventually we might want to do anything more finegrained, but for now\n  this is the simple model.   - Linus ]\n\nChange-Id: I26bcfef2a0d4d3d02da4c522b29615d8ec694600\nSigned-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nAcked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>\nAcked-by: Andy Lutomirski <luto@amacapital.net>\nCc: Pavel Emelyanov <xemul@parallels.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Mark Seaborn <mseaborn@chromium.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Mark Salyzyn <salyzyn@google.com>\nBug: 26038496","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/2ff841fa89cd66f8291828ea657301630858d3a1"},{"sha":"094b859def52db81d6bd075bb3ded0c479df8885","author":{"email":"5d39c857884a1d1ca828769b9ecffa221bdbcccf@gmail.com","name":"Wish Wu"},"message":"msm: null pointer dereferencing\n\nPrevent unintended kernel NULL pointer dereferencing.\n\nOrignal code:\n  hlist_del_rcu(&event->hlist_entry);\n\nFix: Adding pointer check:\n  if(!hlist_unhashed(&p_event->hlist_entry))\n    hlist_del_rcu(&p_event->hlist_entry);\n\nBug: 25364034\nChange-Id: Ieda6d8f4bb567827fa6c7709e9e729905c6c3882\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/094b859def52db81d6bd075bb3ded0c479df8885"},{"sha":"20bf26349d843d9f8bcce16ae4244cd285f0cce5","author":{"email":"1aae5ab9541d66245293c8fc1b9880f5df073631@linaro.org","name":"Anton Vorontsov"},"message":"persistent_ram: Fix buffer size clamping during writes\n\ncommit 484dd30e016eb425b0de871357fff2c9bb93be45 upstream.\n\nThis is a longstanding bug, almost unnoticeable when calling\npersistent_ram_write() for small buffers.\n\nBut when called for large data buffers, the write routine behaves\nincorrectly, as the size may never update: instead of clamping\nthe size to the maximum buffer size, buffer_size_add_clamp() returns\nan error (which is never checked by the write routine, btw).\n\nTo fix this, we now use buffer_size_add() that actually clamps the\nsize to the max value.\n\nAlso remove buffer_size_add_clamp(), it is no longer needed.\n\nChange-Id: Iedde6ab812153ad47aabed3dfe5060356cdeeb55\nSigned-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>\nAcked-by: Colin Cross <ccross@android.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/20bf26349d843d9f8bcce16ae4244cd285f0cce5"},{"sha":"6b5cc177149e07bdb4775559371241e573fb55fd","author":{"email":"d1996fe015c1f347dddf6c16199179596b8014db@codeaurora.org","name":"Naveen Ramaraj"},"message":"msm: perf: validate input argument of ev_constraints functions\n\nValidate input argument before writing into pmu_constraints_codes\narray\n\nChange-Id: Id68b1d2201ab1af783af2236833b1dc894e08cc7\nSigned-off-by: Kishor PK <kpbhat@codeaurora.org>\nSigned-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/6b5cc177149e07bdb4775559371241e573fb55fd"},{"sha":"3713669de529dbfc46f032b3d945acc570ed3f60","author":{"email":"b8b7e8a1740f4a6484e6faf986cb2a9e5fbce020@codeaurora.org","name":"Praveen Chavan"},"message":"msm: vidc: cache-flush encoder output buffers after alloc\n\nFlush output buffers explcitly during registering. This ensures\nany pending CPU writes (i.e meset to 0 after allocation) are\ncommitted right away, or else this may get flushed _after_\nhardware has written the bitstream.\n\nChange-Id: I958466011e7d96c7b5e2691403c8386309997429\nSigned-off-by: Praveen Chavan <pchavan@codeaurora.org>\nSigned-off-by: c_sridur <sridur@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/3713669de529dbfc46f032b3d945acc570ed3f60"},{"sha":"77618284a5e86a6c71dafccfbda4fd1e3cbc5fb0","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Fix race between read and revoke\n\nThis fixes CVE-2015-7550.\n\nThere's a race between keyctl_read() and keyctl_revoke().  If the revoke\nhappens between keyctl_read() checking the validity of a key and the key's\nsemaphore being taken, then the key type read method will see a revoked key.\n\nThis causes a problem for the user-defined key type because it assumes in\nits read method that there will always be a payload in a non-revoked key\nand doesn't check for a NULL pointer.\n\nFix this by making keyctl_read() check the validity of a key after taking\nsemaphore instead of before.\n\nI think the bug was introduced with the original keyrings code.\n\nThis was discovered by a multithreaded test program generated by syzkaller\n(http://github.com/google/syzkaller).  Here's a cleaned up version:\n\n\t#include <sys/types.h>\n\t#include <keyutils.h>\n\t#include <pthread.h>\n\tvoid *thr0(void *arg)\n\t{\n\t\tkey_serial_t key = (unsigned long)arg;\n\t\tkeyctl_revoke(key);\n\t\treturn 0;\n\t}\n\tvoid *thr1(void *arg)\n\t{\n\t\tkey_serial_t key = (unsigned long)arg;\n\t\tchar buffer[16];\n\t\tkeyctl_read(key, buffer, 16);\n\t\treturn 0;\n\t}\n\tint main()\n\t{\n\t\tkey_serial_t key = add_key(\"user\", \"%\", \"foo\", 3, KEY_SPEC_USER_KEYRING);\n\t\tpthread_t th[5];\n\t\tpthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);\n\t\tpthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);\n\t\tpthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);\n\t\tpthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);\n\t\tpthread_join(th[0], 0);\n\t\tpthread_join(th[1], 0);\n\t\tpthread_join(th[2], 0);\n\t\tpthread_join(th[3], 0);\n\t\treturn 0;\n\t}\n\nBuild as:\n\n\tcc -o keyctl-race keyctl-race.c -lkeyutils -lpthread\n\nRun as:\n\n\twhile keyctl-race; do :; done\n\nas it may need several iterations to crash the kernel.  The crash can be\nsummarised as:\n\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\n\tIP: [<ffffffff81279b08>] user_read+0x56/0xa3\n\t...\n\tCall Trace:\n\t [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7\n\t [<ffffffff81277815>] SyS_keyctl+0x83/0xe0\n\t [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f\n\nChange-Id: Id4a5e47860162f62c94bb66728ca9e712f9d89c2\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nCc: stable@vger.kernel.org\nSigned-off-by: James Morris <james.l.morris@oracle.com>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/77618284a5e86a6c71dafccfbda4fd1e3cbc5fb0"},{"sha":"24c7a1a1a7364367c5675f33b7c66bec1fe349c1","author":{"email":"4b8373d016f277527198385ba72fda0feb5da015@hurleysoftware.com","name":"Peter Hurley"},"message":"tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)\n\nioctl(TIOCGETD) retrieves the line discipline id directly from the\nldisc because the line discipline id (c_line) in termios is untrustworthy;\nuserspace may have set termios via ioctl(TCSETS*) without actually\nchanging the line discipline via ioctl(TIOCSETD).\n\nHowever, directly accessing the current ldisc via tty->ldisc is\nunsafe; the ldisc ptr dereferenced may be stale if the line discipline\nis changing via ioctl(TIOCSETD) or hangup.\n\nWait for the line discipline reference (just like read() or write())\nto retrieve the \"current\" line discipline id.\n\nChange-Id: I1205cfb2e0b921d89f1da2a1832811e2ca09fd9a\nCc: <stable@vger.kernel.org>\nSigned-off-by: Peter Hurley <peter@hurleysoftware.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/24c7a1a1a7364367c5675f33b7c66bec1fe349c1"},{"sha":"bd85efc31957341e3e4337e6da693c855226513d","author":{"email":"71255387a32c360dfbe6dfb7aaeb123bf1dc8cb6@kernel.org","name":"Jaegeuk Kim"},"message":"f2fs: catch up to v4.4-rc1\n\nThe last patch is:\n\ncommit beaa57dd986d4f398728c060692fc2452895cfd8\nAuthor: Chao Yu <chao2.yu@samsung.com>\nDate:   Thu Oct 22 18:24:12 2015 +0800\n\n    f2fs: fix to skip shrinking extent nodes\n\n    In f2fs_shrink_extent_tree we should stop shrink flow if we have already\n    shrunk enough nodes in extent cache.\n\nChange-Id: I9a1f4463b1e4418d34473cde5181bed9ff471953\nSigned-off-by: Jaegeuk Kim <jaegeuk@kernel.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/bd85efc31957341e3e4337e6da693c855226513d"},{"sha":"c97b5c0d3ca3da755d7daec9b3a148062b416058","author":{"email":"f66cc59a245d146467efed1402e6d2f55ef6f900@google.com","name":"Patrick Tjin"},"message":"Keep history after reset to 094b859","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/c97b5c0d3ca3da755d7daec9b3a148062b416058"},{"sha":"eca06b455852ca7d29d2ca55a6326d5540e7c329","author":{"email":"73675debcd8a436be48ec22211dcf44fe0df0a64@decadent.org.uk","name":"Ben Hutchings"},"message":"pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic\n\npipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,\nthe first time atomically and the second time not.  The second attempt\nneeds to continue from the iovec position, pipe buffer offset and\nremaining length where the first attempt failed, but currently the\npipe buffer offset and remaining length are reset.  This will corrupt\nthe piped data (possibly also leading to an information leak between\nprocesses) and may also corrupt kernel memory.\n\nThis was fixed upstream by commits f0d1bec9d58d (\"new helper:\ncopy_page_from_iter()\") and 637b58c2887e (\"switch pipe_read() to\ncopy_page_to_iter()\"), but those aren't suitable for stable.  This fix\nfor older kernel versions was made by Seth Jennings for RHEL and I\nhave extracted it from their update.\n\nCVE-2015-1805\n\nBug: 27275324\n\nChange-Id: I459adb9076fcd50ff1f1c557089c4e421b036ec4\nReferences: https://bugzilla.redhat.com/show_bug.cgi?id=1202855\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n(cherry picked from commit 85c34d007116f8a8aafb173966a605fb03532f45)","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/eca06b455852ca7d29d2ca55a6326d5540e7c329"},{"sha":"10f5ed1bd18b0e901cc582ed4f7eaa8c056308a4","author":{"email":"13e7bef22676a7f64bd6d546f977acc0f9eb3737@gmail.com","name":"David Marble"},"message":"flo: defconfig, enable f2fs\n\nWe have all the source. Lets build it.\n\nChange-Id: I2d34df68927df55b97e98c2bcccae0604805184b","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/10f5ed1bd18b0e901cc582ed4f7eaa8c056308a4"},{"sha":"b0df0b6aad22a338f1da9707b64732a8ce8534c7","author":{"email":"73675debcd8a436be48ec22211dcf44fe0df0a64@decadent.org.uk","name":"Ben Hutchings"},"message":"pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic\n\npipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,\nthe first time atomically and the second time not.  The second attempt\nneeds to continue from the iovec position, pipe buffer offset and\nremaining length where the first attempt failed, but currently the\npipe buffer offset and remaining length are reset.  This will corrupt\nthe piped data (possibly also leading to an information leak between\nprocesses) and may also corrupt kernel memory.\n\nThis was fixed upstream by commits f0d1bec9d58d (\"new helper:\ncopy_page_from_iter()\") and 637b58c2887e (\"switch pipe_read() to\ncopy_page_to_iter()\"), but those aren't suitable for stable.  This fix\nfor older kernel versions was made by Seth Jennings for RHEL and I\nhave extracted it from their update.\n\nCVE-2015-1805\n\nChange-Id: Ic254714818c7e5e824f4e238283c25577a00c219\nReferences: https://bugzilla.redhat.com/show_bug.cgi?id=1202855\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/b0df0b6aad22a338f1da9707b64732a8ce8534c7"},{"sha":"2ab75015a246fc29d55b44cf06b7a4b1c9cd6ec6","author":{"email":"f66cc59a245d146467efed1402e6d2f55ef6f900@google.com","name":"Patrick Tjin"},"message":"Revert \"Keep history after reset to 094b859\"\n\nThis reverts commit c97b5c0d3ca3da755d7daec9b3a148062b416058, reversing\nchanges made to 6b5cc177149e07bdb4775559371241e573fb55fd.\n\nChange-Id: I2fbf3d21c74ff886640f6ba54d783a8c3d0a75b3\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/2ab75015a246fc29d55b44cf06b7a4b1c9cd6ec6"},{"sha":"1fac73337080712109029302599945d1ac36c799","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission before processing\n\nfor SET_OEM_DATA_REQ IOCTL\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing SET_OEM_DATA_REQ IOCTLs, making\nsure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: I651656fe11d4235232b76c972b5460b57e608449\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/1fac73337080712109029302599945d1ac36c799"},{"sha":"e9dcd5aa01734b019c793220531e4ef1d82959f8","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission before processing\n\nfor SET_CHAR_GET_NONE IOCTL\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing SET_CHAR_GET_NONE IOCTLs, making\nsure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: Iccf25a9d1f1a7c13d3aaf2fc4bd3aebba740dbb2\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/e9dcd5aa01734b019c793220531e4ef1d82959f8"},{"sha":"fd13b59e5a75b761f68fe34f09df1dce7a49acc2","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission before processing\n\nfor SET_PACKET_FILTER IOCTL\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing SET_PACKET_FILTER IOCTL, making\nsure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: I1edc65ee26c5e3e4260e0f6546434b0137493396\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/fd13b59e5a75b761f68fe34f09df1dce7a49acc2"},{"sha":"fbb8f120ee729d47869f0bebe5bc31e83bcf2876","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission\n\nfor SET_VAR_INTS_GETNONE IOCTL\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing SET_VAR_INTS_GETNONE, making\nsure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: Ia2465433aab6366160a167a62ca03e0ba720bcdb\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/fbb8f120ee729d47869f0bebe5bc31e83bcf2876"},{"sha":"518fd80981eefa9715e0851260b2c7aeb86551d7","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission\n\nfor QCSAP_IOCTL_SETWPSIE\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing QCSAP_IOCTL_SETWPSIE IOCTL,\nmaking sure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: I66acff95d6151b32f1cb3c36a164e1de021e1e30\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/518fd80981eefa9715e0851260b2c7aeb86551d7"},{"sha":"86fd66a451b2549f990b71013220e0a3f46b5a00","author":{"email":"dd96470313a142e6011d731d2a736a163f0b4735@qti.qualcomm.com","name":"Mukul Sharma"},"message":"wlan:Check priviledge permission\n\nfor QCSAP_IOCTL_DISASSOC_STA\n\nKernel assumes all SET IOCTL commands are assigned with even\nnumbers. But in our WLAN driver, some SET IOCTLS are assigned with\nodd numbers. This leads kernel fail to check, for some SET IOCTLs,\nwhether user has the right permission to do SET operation.\nHence, in driver, before processing QCSAP_IOCTL_DISASSOC_STA IOCTL,\nmaking sure user task has right permission to process the command.\n\nBug: 27104184\nChange-Id: I7928789c0ce94a2b81495064496766b9e62d6ed8\nSigned-off-by: Yuan Lin <yualin@google.com>","distinct":false,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/86fd66a451b2549f990b71013220e0a3f46b5a00"}]}