{"push_id":1091119047,"size":23,"distinct_size":23,"ref":"refs/heads/mkm","head":"5cf72ee86ad8577d803239d4a736ee0d0c3603c5","before":"a34d2571bb639441c8a0a67b116abdd9fde506f7","commits":[{"sha":"5a90719c36967703b9f5aeccb9f4f4c853e21e81","author":{"email":"cd0af677d69950d90648086320724e7e50659c4c@cyanogenmod.org","name":"Dan Pasanen"},"message":"Revert \"msm: camera: 8992: 8994: Revert \"(CR): temp fix\"\"\n\nThis reverts commit a514df0f2f711f3d84d69e2af0c1cdad647109cd.","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/5a90719c36967703b9f5aeccb9f4f4c853e21e81"},{"sha":"66975552628e11391cd8c0ff6e28c1d4f3de174f","author":{"email":"cd0af677d69950d90648086320724e7e50659c4c@cyanogenmod.org","name":"Dan Pasanen"},"message":"dts: mmi: only include clark dtbs for msm8992\n\n* no reason to include an extra 2.5mb of unused dtbs for\n  msm8992 (clark) devices\n\nChange-Id: I24baaf327c3389a6173c8d0951f514a15405e56e","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/66975552628e11391cd8c0ff6e28c1d4f3de174f"},{"sha":"fe6412f712c88e52992642752037c351c0f71847","author":{"email":"cd0af677d69950d90648086320724e7e50659c4c@cyanogenmod.org","name":"Dan Pasanen"},"message":"dts: mot_inx_570: enable ulps\n\nChange-Id: I718bb6df9f505bcbc8aedc7325122f6e8ebf4cb8","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/fe6412f712c88e52992642752037c351c0f71847"},{"sha":"f6fb7c0ddfcc31bdba8c15d16c8917ad90e2d700","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"tcp_cubic: better follow cubic curve after idle period\n\nJana Iyengar found an interesting issue on CUBIC :\n\nThe epoch is only updated/reset initially and when experiencing losses.\nThe delta \"t\" of now - epoch_start can be arbitrary large after app idle\nas well as the bic_target. Consequentially the slope (inverse of\nca->cnt) would be really large, and eventually ca->cnt would be\nlower-bounded in the end to 2 to have delayed-ACK slow-start behavior.\n\nThis particularly shows up when slow_start_after_idle is disabled\nas a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle\ntime.\n\nJana initial fix was to reset epoch_start if app limited,\nbut Neal pointed out it would ask the CUBIC algorithm to recalculate the\ncurve so that we again start growing steeply upward from where cwnd is\nnow (as CUBIC does just after a loss). Ideally we'd want the cwnd growth\ncurve to be the same shape, just shifted later in time by the amount of\nthe idle period.\n\nChange-Id: I5a6b57d38d85c1e685835061888e719d240350dc\nReported-by: Jana Iyengar <jri@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Sangtae Ha <sangtae.ha@gmail.com>\nCc: Lawrence Brakmo <lawrence@brakmo.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/f6fb7c0ddfcc31bdba8c15d16c8917ad90e2d700"},{"sha":"db8f8095d78576b0d4d73662a30210770123fcb7","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"tcp_cubic: do not set epoch_start in the future\n\nTracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start\nis normally set at ACK processing time, not at send time.\n\nDoing a proper fix would need to add an additional state variable,\nand does not seem worth the trouble, given CUBIC bug has been there\nforever before Jana noticed it.\n\nLet's simply not set epoch_start in the future, otherwise\nbictcp_update() could overflow and CUBIC would again\ngrow cwnd too fast.\n\nThis was detected thanks to a packetdrill test Neal wrote that was flaky\nbefore applying this fix.\n\nChange-Id: Ifd1e4be175824a31619ff4c1dc973f82346b799d\nFixes: 30927520dbae (\"tcp_cubic: better follow cubic curve after idle period\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nCc: Jana Iyengar <jri@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/db8f8095d78576b0d4d73662a30210770123fcb7"},{"sha":"a2b0e7bcdb8f8adbbc6fe7c6a389eab6aaf71c40","author":{"email":"518d07701a80fb29f0da45c7c615106b9be9d5c6@redhat.com","name":"Marcelo Leitner"},"message":"ipv6: addrconf: validate new MTU before applying it\n\nCurrently we don't check if the new MTU is valid or not and this allows\none to configure a smaller than minimum allowed by RFCs or even bigger\nthan interface own MTU, which is a problem as it may lead to packet\ndrops.\n\nIf you have a daemon like NetworkManager running, this may be exploited\nby remote attackers by forging RA packets with an invalid MTU, possibly\nleading to a DoS. (NetworkManager currently only validates for values\ntoo small, but not for too big ones.)\n\nThe fix is just to make sure the new value is valid. That is, between\nIPV6_MIN_MTU and interface's MTU.\n\nNote that similar check is already performed at\nndisc_router_discovery(), for when kernel itself parses the RA.\n\nChange-Id: Iab190dc7a1215f682357d6c5eeb8fad8fbb73527\nSigned-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>\nSigned-off-by: Sabrina Dubroca <sd@queasysnail.net>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/a2b0e7bcdb8f8adbbc6fe7c6a389eab6aaf71c40"},{"sha":"10cbd55f5ad19062316f6df6379c22bc6632255e","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","name":"Hannes Frederic Sowa"},"message":"net: add validation for the socket syscall protocol argument\n\n郭永刚 reported that one could simply crash the kernel as root by\nusing a simple program:\n\n\tint socket_fd;\n\tstruct sockaddr_in addr;\n\taddr.sin_port = 0;\n\taddr.sin_addr.s_addr = INADDR_ANY;\n\taddr.sin_family = 10;\n\n\tsocket_fd = socket(10,3,0x40000000);\n\tconnect(socket_fd , &addr,16);\n\nAF_INET, AF_INET6 sockets actually only support 8-bit protocol\nidentifiers. inet_sock's skc_protocol field thus is sized accordingly,\nthus larger protocol identifiers simply cut off the higher bits and\nstore a zero in the protocol fields.\n\nThis could lead to e.g. NULL function pointer because as a result of\nthe cut off inet_num is zero and we call down to inet_autobind, which\nis NULL for raw sockets.\n\nkernel: Call Trace:\nkernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70\nkernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80\nkernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110\nkernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80\nkernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200\nkernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10\nkernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89\n\nI found no particular commit which introduced this problem.\n\nChange-Id: I4354ae52b678cdd2de0d21ca934d956bb2929473\nCVE: CVE-2015-8543\nCc: Cong Wang <cwang@twopensource.com>\nReported-by: 郭永刚 <guoyonggang@360.cn>\nSigned-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/10cbd55f5ad19062316f6df6379c22bc6632255e"},{"sha":"f6496138adb58698d31a81f5031c66619a1704ad","author":{"email":"fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","name":"David S. Miller"},"message":"bluetooth: Validate socket address length in sco_sock_bind().\n\nChange-Id: I9e77c85cdf04a8156c774b5c77ef74af0ae46941\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/f6496138adb58698d31a81f5031c66619a1704ad"},{"sha":"4854b297db047fb93c0f71e705b94f4adb67f165","author":{"email":"4452d71687b6bc2c9389c3349fdc17fbd73b833b@queasysnail.net","name":"Sabrina Dubroca"},"message":"net: add length argument to skb_copy_and_csum_datagram_iovec\n\nWithout this length argument, we can read past the end of the iovec in\nmemcpy_toiovec because we have no way of knowing the total length of the\niovec's buffers.\n\nThis is needed for stable kernels where 89c22d8c3b27 (\"net: Fix skb\ncsum races when peeking\") has been backported but that don't have the\nioviter conversion, which is almost all the stable trees <= 3.18.\n\nThis also fixes a kernel crash for NFS servers when the client uses\n -onfsvers=3,proto=udp to mount the export.\n\nChange-Id: I1865e3d7a1faee42a5008a9ad58c4d3323ea4bab\nSigned-off-by: Sabrina Dubroca <sd@queasysnail.net>\nReviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/4854b297db047fb93c0f71e705b94f4adb67f165"},{"sha":"22e5920032172088ec77139c4e3773eaf53247da","author":{"email":"fe09bc2ef2737a3258f978e26226dcbac1b3f948@randazzo.fr","name":"Benjamin Randazzo"},"message":"md: use kzalloc() when bitmap is disabled\n\ncommit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.\n\nIn drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a\nmdu_bitmap_file_t called \"file\".\n\n5769         file = kmalloc(sizeof(*file), GFP_NOIO);\n5770         if (!file)\n5771                 return -ENOMEM;\n\nThis structure is copied to user space at the end of the function.\n\n5786         if (err == 0 &&\n5787             copy_to_user(arg, file, sizeof(*file)))\n5788                 err = -EFAULT\n\nBut if bitmap is disabled only the first byte of \"file\" is initialized\nwith zero, so it's possible to read some bytes (up to 4095) of kernel\nspace memory from user space. This is an information leak.\n\n5775         /* bitmap disabled, zero the first byte and copy out */\n5776         if (!mddev->bitmap_info.file)\n5777                 file->pathname[0] = '\\0';\n\nChange-Id: If305dd121434d2713862f4b72d63c27701f07c3d\nSigned-off-by: Benjamin Randazzo <benjamin@randazzo.fr>\nSigned-off-by: NeilBrown <neilb@suse.com>\n[lizf: Backported to 3.4: fix both branches]\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/22e5920032172088ec77139c4e3773eaf53247da"},{"sha":"f21149a4f9536949f610470c94e427919f3e6b05","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Fix handling of stored error in a negatively instantiated user key\n\nIf a user key gets negatively instantiated, an error code is cached in the\npayload area.  A negatively instantiated key may be then be positively\ninstantiated by updating it with valid data.  However, the ->update key\ntype method must be aware that the error code may be there.\n\nThe following may be used to trigger the bug in the user key type:\n\n    keyctl request2 user user \"\" @u\n    keyctl add user user \"a\" @u\n\nwhich manifests itself as:\n\n\tBUG: unable to handle kernel paging request at 00000000ffffff8a\n\tIP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046\n\tPGD 7cc30067 PUD 0\n\tOops: 0002 [#1] SMP\n\tModules linked in:\n\tCPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49\n\tHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011\n\ttask: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000\n\tRIP: 0010:[<ffffffff810a376f>]  [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280\n\t [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046\n\tRSP: 0018:ffff88003dd8bdb0  EFLAGS: 00010246\n\tRAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001\n\tRDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82\n\tRBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000\n\tR10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82\n\tR13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700\n\tFS:  0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b\n\tCR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0\n\tStack:\n\t ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82\n\t ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5\n\t ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620\n\tCall Trace:\n\t [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136\n\t [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129\n\t [<     inline     >] __key_update security/keys/key.c:730\n\t [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908\n\t [<     inline     >] SYSC_add_key security/keys/keyctl.c:125\n\t [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60\n\t [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185\n\nNote the error code (-ENOKEY) in EDX.\n\nA similar bug can be tripped by:\n\n    keyctl request2 trusted user \"\" @u\n    keyctl add trusted user \"a\" @u\n\nThis should also affect encrypted keys - but that has to be correctly\nparameterised or it will fail with EINVAL before getting to the bit that\nwill crashes.\n\nChange-Id: I1b5343c647f0e40194dd0695e983a3083003e7d6\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nAcked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>\nSigned-off-by: James Morris <james.l.morris@oracle.com>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/f21149a4f9536949f610470c94e427919f3e6b05"},{"sha":"b473d68b31dbad99b9f432390b18c3673d685997","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Fix race between key destruction and finding a keyring by name\n\nThere appears to be a race between:\n\n (1) key_gc_unused_keys() which frees key->security and then calls\n     keyring_destroy() to unlink the name from the name list\n\n (2) find_keyring_by_name() which calls key_permission(), thus accessing\n     key->security, on a key before checking to see whether the key usage is 0\n     (ie. the key is dead and might be cleaned up).\n\nFix this by calling ->destroy() before cleaning up the core key data -\nincluding key->security.\n\nChange-Id: I4b9b89af020e6348af095e9014bf23b5eb1a9ef9\nReported-by: Petr Matousek <pmatouse@redhat.com>\nSigned-off-by: David Howells <dhowells@redhat.com>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/b473d68b31dbad99b9f432390b18c3673d685997"},{"sha":"3bb879e6b775914b2c859fdd2c20cd38eea2bae3","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring\n\nThe following sequence of commands:\n\n    i=`keyctl add user a a @s`\n    keyctl request2 keyring foo bar @t\n    keyctl unlink $i @s\n\ntries to invoke an upcall to instantiate a keyring if one doesn't already\nexist by that name within the user's keyring set.  However, if the upcall\nfails, the code sets keyring->type_data.reject_error to -ENOKEY or some\nother error code.  When the key is garbage collected, the key destroy\nfunction is called unconditionally and keyring_destroy() uses list_empty()\non keyring->type_data.link - which is in a union with reject_error.\nSubsequently, the kernel tries to unlink the keyring from the keyring names\nlist - which oopses like this:\n\n\tBUG: unable to handle kernel paging request at 00000000ffffff8a\n\tIP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88\n\t...\n\tWorkqueue: events key_garbage_collector\n\t...\n\tRIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88\n\tRSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203\n\tRAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000\n\tRDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40\n\tRBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000\n\tR10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900\n\tR13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000\n\t...\n\tCR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0\n\t...\n\tCall Trace:\n\t [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f\n\t [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351\n\t [<ffffffff8105ec9b>] process_one_work+0x28e/0x547\n\t [<ffffffff8105fd17>] worker_thread+0x26e/0x361\n\t [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8\n\t [<ffffffff810648ad>] kthread+0xf3/0xfb\n\t [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2\n\t [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70\n\t [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2\n\nNote the value in RAX.  This is a 32-bit representation of -ENOKEY.\n\nThe solution is to only call ->destroy() if the key was successfully\ninstantiated.\n\nChange-Id: Ia52370813b7e8231fdd99d2a208340af1c7b4007\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/3bb879e6b775914b2c859fdd2c20cd38eea2bae3"},{"sha":"79b0c26e25f3c3c08d4a810e2980d6200d2734c9","author":{"email":"3ca33452d0ba398506359975e18b2014a884f2c8@yandex-team.ru","name":"Roman Gushchin"},"message":"fuse: break infinite loop in fuse_fill_write_pages()\n\nI got a report about unkillable task eating CPU. Further\ninvestigation shows, that the problem is in the fuse_fill_write_pages()\nfunction. If iov's first segment has zero length, we get an infinite\nloop, because we never reach iov_iter_advance() call.\n\nFix this by calling iov_iter_advance() before repeating an attempt to\ncopy data from userspace.\n\nA similar problem is described in 124d3b7041f (\"fix writev regression:\npan hanging unkillable and un-straceable\"). If zero-length segmend\nis followed by segment with invalid address,\niov_iter_fault_in_readable() checks only first segment (zero-length),\niov_iter_copy_from_user_atomic() skips it, fails at second and\nreturns zero -> goto again without skipping zero-length segment.\n\nPatch calls iov_iter_advance() before goto again: we'll skip zero-length\nsegment at second iteraction and iov_iter_fault_in_readable() will detect\ninvalid address.\n\nSpecial thanks to Konstantin Khlebnikov, who helped a lot with the commit\ndescription.\n\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Maxim Patlasov <mpatlasov@parallels.com>\nCc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>\nSigned-off-by: Roman Gushchin <klamm@yandex-team.ru>\nSigned-off-by: Miklos Szeredi <miklos@szeredi.hu>\nFixes: ea9b9907b82a (\"fuse: implement perform_write\")\nCc: <stable@vger.kernel.org>\n\nConflicts:\n\tfs/fuse/file.c\n\nChange-Id: Id37193373294dd43191469389cfe68ca1736a54b","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/79b0c26e25f3c3c08d4a810e2980d6200d2734c9"},{"sha":"46c2f6464e74c5b76a779bf4e0c2e08da8d96178","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: If7e9a6e85a2abaee640642646d1087920c18ad90\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/MoKee/android_kernel_motorola_msm8992/commits/46c2f6464e74c5b76a779bf4e0c2e08da8d96178"},{"sha":"aa36ac3f815e171da3f5d3583cb7d17a331e02d0","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: Iabce3731106464afa734ad831a589c6955e056b0\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/MoKee/android_kernel_motorola_msm8992/commits/aa36ac3f815e171da3f5d3583cb7d17a331e02d0"},{"sha":"c327a712bd78444face6e56e965d262459067ad5","author":{"email":"73675debcd8a436be48ec22211dcf44fe0df0a64@decadent.org.uk","name":"Ben Hutchings"},"message":"pipe: Fix buffer offset after partially failed read\n\nQuoting the RHEL advisory:\n\n> It was found that the fix for CVE-2015-1805 incorrectly kept buffer\n> offset and buffer length in sync on a failed atomic read, potentially\n> resulting in a pipe buffer state corruption. A local, unprivileged user\n> could use this flaw to crash the system or leak kernel memory to user\n> space. (CVE-2016-0774, Moderate)\n\nThe same flawed fix was applied to stable branches from 2.6.32.y to\n3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.\nWe need to give pipe_iov_copy_to_user() a separate offset variable\nand only update the buffer offset if it succeeds.\n\nChange-Id: I988802f38acf40c7671fa0978880928b02d29b56\nReferences: https://rhn.redhat.com/errata/RHSA-2016-0103.html\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/c327a712bd78444face6e56e965d262459067ad5"},{"sha":"7b7be271519bc7c32f36759d2c8584c0aad80544","author":{"email":"785dce9813c74aa517a07b7a1160c1a9cdebd7be@codeaurora.org","name":"Swetha Chikkaboraiah"},"message":"msm: perf: Protect buffer overflow due to malicious user\n\nIn function krait_pmu_disable_event, parameter hwc comes from\nuserspace and is untrusted.The function krait_clearpmu is called\nafter the function get_krait_evtinfo.\nFunction get_krait_evtinfo as parameter krait_evt_type variable\nwhich is used to extract the groupcode(reg) which is bound to\nKRAIT_MAX_L1_REG (is 3). After validation,one code path modifies\ngroupcode(reg):If this code path executes, groupcode(reg) can be\n3,4, 5, or 6. In krait_clearpmu groupcode used to access array\nkrait_functions whose size is 3. Since groupcode can be 3,4,5,6\naccessing array krait_functions lead to bufferoverlflow.\nThis change will validate groupcode not to exceed 3 .\n\nChange-Id: I48c92adda137d8a074b4e1a367a468195a810ca1\nCRs-fixed: 962450\nSigned-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/7b7be271519bc7c32f36759d2c8584c0aad80544"},{"sha":"98170f475f1ff65b00b85cdf97f3c5c56fcac213","author":{"email":"248dd96652a047b675d8f9c63c018de72461a2f7@gmail.com","name":"Andrey Konovalov"},"message":"ALSA: usb-audio: avoid freeing umidi object twice\n\nThe 'umidi' object will be free'd on the error path by snd_usbmidi_free()\nwhen tearing down the rawmidi interface. So we shouldn't try to free it\nin snd_usbmidi_create() after having registered the rawmidi interface.\n\nFound by KASAN.\n\nSigned-off-by: Andrey Konovalov <andreyknvl@gmail.com>\nAcked-by: Clemens Ladisch <clemens@ladisch.de>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/98170f475f1ff65b00b85cdf97f3c5c56fcac213"},{"sha":"d2d7a49c1be61069c2809cf1c1da2476e0fb8c24","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: timer: Fix double unlink of active_list\n\nALSA timer instance object has a couple of linked lists and they are\nunlinked unconditionally at snd_timer_stop().  Meanwhile\nsnd_timer_interrupt() unlinks it, but it calls list_del() which leaves\nthe element list itself unchanged.  This ends up with unlinking twice,\nand it was caught by syzkaller fuzzer.\n\nThe fix is to use list_del_init() variant properly there, too.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_motorola_msm8992/commits/d2d7a49c1be61069c2809cf1c1da2476e0fb8c24"}]}