{"push_id":996871979,"size":10,"distinct_size":10,"ref":"refs/heads/cm-13.0","head":"cb5c603ff34f32f8c678dc59629a1f9486c5e4bc","before":"0fbc49c02729d613af84d89bf90a653138af8e97","commits":[{"sha":"f30c1afe45b610ece5be705c2c0e4163debde37d","author":{"email":"eee62f459f15dcddf87a8df69e8328e2a2562028@kernel.org","name":"Minchan Kim"},"message":"zsmalloc: correct fragile [kmap|kunmap]_atomic use\n\nThe kunmap_atomic should use virtual address getting by kmap_atomic.\nHowever, some pieces of code in zsmalloc uses modified address, not the\none got by kmap_atomic for kunmap_atomic.\n\nIt's okay for working because zsmalloc modifies the address inner\nPAGE_SIZE bounday so it works with current kmap_atomic's implementation.\nBut it's still fragile with potential changing of kmap_atomic so let's\ncorrect it.\n\nI got a subtle bug when I implemented a new feature of zsmalloc\n(compaction) due to a link's mishandling (the link was over page\nboundary).  Although it was totally my mistake, it took a while to find\nthe cause because an unpredictable kmapped address was unmapped causing an\nalmost random crash.\n\nChange-Id: Ic637e7d65e743a42df5833566054634c9a08f86d\nSigned-off-by: Minchan Kim <minchan@kernel.org>\nCc: Nitin Gupta <ngupta@vflare.org>\nCc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nCc: Seth Jennings <sjennings@variantweb.net>\nCc: Jerome Marchand <jmarchan@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/f30c1afe45b610ece5be705c2c0e4163debde37d"},{"sha":"1f343b0dadaa02d891499617afa68c14aa05785d","author":{"email":"6c55b1e1f53a3eae8a57c94118796a0d4fab02ed@gmail.com","name":"Ganesh Mahendran"},"message":"mm/zsmalloc: allocate exactly size of struct zs_pool\n\nIn zs_create_pool(), we allocate memory more then sizeof(struct zs_pool)\n  ovhd_size = roundup(sizeof(*pool), PAGE_SIZE);\n\nThis patch allocate memory of exactly needed size.\n\nChange-Id: Id0ada356009c92bf791c94be073f4467f7bb1aac\nSigned-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>\nAcked-by: Minchan Kim <minchan@kernel.org>\nCc: Nitin Gupta <ngupta@vflare.org>\nCc: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/1f343b0dadaa02d891499617afa68c14aa05785d"},{"sha":"3983fe431b80000ffe79f40664e67681020524e8","author":{"email":"8c1011c9d06fc72acd93645d683782ab9543044d@google.com","name":"Michael Halcrow"},"message":"eCryptfs: Remove buggy and unnecessary write in file name decode routine\n\nDmitry Chernenkov used KASAN to discover that eCryptfs writes past the\nend of the allocated buffer during encrypted filename decoding. This\nfix corrects the issue by getting rid of the unnecessary 0 write when\nthe current bit offset is 2.\n\nChange-Id: Id8e04a580e550495c46cd36fec430a1ec4342940\nSigned-off-by: Michael Halcrow <mhalcrow@google.com>\nReported-by: Dmitry Chernenkov <dmitryc@google.com>\nSuggested-by: Kees Cook <keescook@chromium.org>\nCc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions\nSigned-off-by: Tyler Hicks <tyhicks@canonical.com>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/3983fe431b80000ffe79f40664e67681020524e8"},{"sha":"416819c0c805eb5767196fe627b6ee739730af3f","author":{"email":"8a741aa8cbd77ebc4a56ddb528ce9fd15d42f034@xmission.com","name":"Eric W. Biederman"},"message":"mnt: Only change user settable mount flags in remount\n\ncommit a6138db815df5ee542d848318e5dae681590fccd upstream.\n\nKenton Varda <kenton@sandstorm.io> discovered that by remounting a\nread-only bind mount read-only in a user namespace the\nMNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user\nto the remount a read-only mount read-write.\n\nCorrect this by replacing the mask of mount flags to preserve\nwith a mask of mount flags that may be changed, and preserve\nall others.   This ensures that any future bugs with this mask and\nremount will fail in an easy to detect way where new mount flags\nsimply won't change.\n\nChange-Id: I8ab8bda03a14b9b43e78f1dc6c818bbec048e986\nAcked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>\nSigned-off-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Francis Moreau <francis.moro@gmail.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/416819c0c805eb5767196fe627b6ee739730af3f"},{"sha":"7887a7f7859ffd355ccf62ee967ec0c4d336a85c","author":{"email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","name":"Hans de Goede"},"message":"cgroup: Take css_set_lock from cgroup_css_sets_empty()\n\nAs indicated in the comment above cgroup_css_sets_empty it needs the\ncss_set_lock. But neither of the 2 call points have it, so rather then fixing\nthe callers just take the lock inside cgroup_css_sets_empty().\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nChange-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/7887a7f7859ffd355ccf62ee967ec0c4d336a85c"},{"sha":"e124193e7e630a051669dcaa60043fd3079f4687","author":{"email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","name":"Hans de Goede"},"message":"cgroup: Fix use after free of cgrp (cgrp->css_sets)\n\nRunning a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10\n(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption\nerrors when build with CONFIG_DEBUG_LIST, and the backtrace always shows\nfree_css_set_work as the function making the problematic list_del call.\n\nI've tracked this doen to a use after free of the cgrp struct, specifically\nof the cgrp->css_sets list_head, which gets cleared by free_css_set_work.\n\nSince free_css_set_work runs form a workqueue, it is possible for it to not be\ndone with clearing the list when the cgrp gets free-ed. To avoid this the code\nadding the links increases cgrp->count, and the freeing code running from the\nworkqueue decreases cgrp->count *after* doing list_del, and then if the count\ngoes to 0 calls cgroup_wakeup_rmdir_waiter().\n\nHowever cgroup_rmdir() is missing a check for cgrp->count != 0, causing it\nto still continue with the rmdir (which leads to the free-ing of the cgrp),\nbefore free_css_set_work is done. Sometimes the free-ed memory is re-used\nbefore free_css_set_work gets around to unlinking link->cgrp_link_list,\ntriggering the list_del list corruption messages.\n\nThis patch fixes this by properly checking for cgrp->count != 0 and waiting\nfor the cgroup_rmdir_waitq in that case.\n\nChange-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/e124193e7e630a051669dcaa60043fd3079f4687"},{"sha":"0eae93c83c860b09079e1c13b783c16c4f190dea","author":{"email":"d282495bfb62d367009a66784cabed6d13acc2f2@codeaurora.org","name":"Steve Muckle"},"message":"sched: fix race between try_to_wake_up() and move_task()\n\nUntil a task's state has been seen as interruptible/uninterruptible\nand it is no longer on_cpu, it is possible that the task may move\nto another CPU (load balancing may cause this). Here is an example\nwhere the race condition results in incorrect operation:\n\n- cpu 0 calls put_prev_task on task A, task A's state is TASK_RUNNING\n- cpu 0 runs task B, which attempts to wake up A\n- cpu 0 begins try_to_wake_up(), recording src_cpu for task A as cpu 0\n- cpu 1 then pulls task A (perhaps due to idle balance)\n- cpu 1 runs task A, which then sleeps, becoming INTERRUPTIBLE\n- cpu 0 continues in try_to_wake_up(), thinking task A's previous\n  cpu is 0, where it is actually 1\n- if select_task_rq returns cpu 0, task A will be woken up on cpu 0\n  without properly updating its cpu to 0 in set_task_cpu()\n\nCRs-Fixed: 665958\nChange-Id: Icee004cb320bd8edfc772d9f74e670a9d4978a99\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/0eae93c83c860b09079e1c13b783c16c4f190dea"},{"sha":"d76cc40a0d34f27e566f66d7bfba86e04cdb6ebb","author":{"email":"eec72676ad9a62f2727dfed6d270d98c0d02adec@linux.intel.com","name":"Kirill A. Shutemov"},"message":"mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support\n\nSasha Levin found a NULL pointer dereference that is due to a missing\npage table lock, which in turn is due to the pmd entry in question being\na transparent huge-table entry.\n\nThe code - introduced in commit 1998cc048901 (\"mm: make\nmadvise(MADV_WILLNEED) support swap file prefetch\") - correctly checks\nfor this situation using pmd_none_or_trans_huge_or_clear_bad(), but it\nturns out that that function doesn't work correctly.\n\npmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would\ntrigger if the transparent hugepage bit was set, but it doesn't do that\nif pmd_numa() is also set. Note that the NUMA bit only gets set on real\nNUMA machines, so people trying to reproduce this on most normal\ndevelopment systems would never actually trigger this.\n\nFix it by removing the very subtle (and subtly incorrect) expectation,\nand instead just checking pmd_trans_huge() explicitly.\n\nReported-by: Sasha Levin <sasha.levin@oracle.com>\nAcked-by: Andrea Arcangeli <aarcange@redhat.com>\n[ Additionally remove the now stale test for pmd_trans_huge() inside the\n  pmd_bad() case - Linus ]\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: I3f3763f236ef102de735297cd175cf514d40d28f","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/d76cc40a0d34f27e566f66d7bfba86e04cdb6ebb"},{"sha":"18864b2c835f892b710357a202306957455caa86","author":{"email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk","name":"Al Viro"},"message":"vfs: new internal helper: mnt_has_parent(mnt)\n\nvfsmounts have ->mnt_parent pointing either to a different vfsmount\nor to itself; it's never NULL and termination condition in loops\ntraversing the tree towards root is mnt == mnt->mnt_parent.  At least\none place (see the next patch) is confused about what's going on;\nlet's add an explicit helper checking it right way and use it in\nall places where we need it.  Not that there had been too many,\nbut...\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\n(cherry picked from commit b2dba1af3c4157040303a76d25216b1713d333d0)\nCVE-2014-7970\nBugLink: http://bugs.launchpad.net/bugs/1383356\nSigned-off-by: Luis Henriques <luis.henriques@canonical.com>\nAcked-by: Stefan Bader <stefan.bader@canonical.com>\nAcked-by: Andy Whitcroft <apw@canonical.com>\nSigned-off-by: Andy Whitcroft <apw@canonical.com>\n\nChange-Id: Iaa5ab510804f3b17fe71197b8919d663a416bf05","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/18864b2c835f892b710357a202306957455caa86"},{"sha":"cb5c603ff34f32f8c678dc59629a1f9486c5e4bc","author":{"email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk","name":"Al Viro"},"message":"vfs: more mnt_parent cleanups\n\na) mount --move is checking that ->mnt_parent is non-NULL before\nlooking if that parent happens to be shared; ->mnt_parent is never\nNULL and it's not even an misspelled !mnt_has_parent()\n\nb) pivot_root open-codes is_path_reachable(), poorly.\n\nc) so does path_is_under(), while we are at it.\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\n(backported from commit afac7cba7ed31968a95e181dc25e204e45009ea8)\nCVE-2014-7970\nBugLink: http://bugs.launchpad.net/bugs/1383356\nSigned-off-by: Luis Henriques <luis.henriques@canonical.com>\nAcked-by: Stefan Bader <stefan.bader@canonical.com>\nAcked-by: Andy Whitcroft <apw@canonical.com>\nSigned-off-by: Andy Whitcroft <apw@canonical.com>\n\nChange-Id: I6b2297f46388f135c1b760a37d45efc0e33542db","distinct":true,"url":"https://api.github.com/repos/Saylance/android_kernel_samsung_smdk4412/commits/cb5c603ff34f32f8c678dc59629a1f9486c5e4bc"}]}