{"push_id":2606363366,"size":269,"distinct_size":269,"ref":"refs/heads/o8x-caf","head":"c9175e9abd6b294aebeca1e819755111767e8664","before":"876f060560cc8c29ae40580772a0ec440933f91a","commits":[{"sha":"422494a9e07463388a1c7f3dd4f910c032a060a3","author":{"name":"Maciej W. Rozycki","email":"78f3a3d9d6e4d907a7d12e475d0a751d6b7e256b@mips.com"},"message":"MIPS: ptrace: Expose FIR register through FP regset\n\ncommit 71e909c0cdad28a1df1fa14442929e68615dee45 upstream.\n\nCorrect commit 7aeb753b5353 (\"MIPS: Implement task_user_regset_view.\")\nand expose the FIR register using the unused 4 bytes at the end of the\nNT_PRFPREG regset.  Without that register included clients cannot use\nthe PTRACE_GETREGSET request to retrieve the complete FPU register set\nand have to resort to one of the older interfaces, either PTRACE_PEEKUSR\nor PTRACE_GETFPREGS, to retrieve the missing piece of data.  Also the\nregister is irreversibly missing from core dumps.\n\nThis register is architecturally hardwired and read-only so the write\npath does not matter.  Ignore data supplied on writes then.\n\nFixes: 7aeb753b5353 (\"MIPS: Implement task_user_regset_view.\")\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Maciej W. Rozycki <macro@mips.com>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: linux-mips@linux-mips.org\nCc: <stable@vger.kernel.org> # 3.13+\nPatchwork: https://patchwork.linux-mips.org/patch/19273/\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/422494a9e07463388a1c7f3dd4f910c032a060a3"},{"sha":"f363b0cafb77370352d7943beccc8826cb3c8b2e","author":{"name":"Maciej W. Rozycki","email":"78f3a3d9d6e4d907a7d12e475d0a751d6b7e256b@mips.com"},"message":"MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs\n\ncommit 9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream.\n\nCheck the TIF_32BIT_FPREGS task setting of the tracee rather than the\ntracer in determining the layout of floating-point general registers in\nthe floating-point context, correcting access to odd-numbered registers\nfor o32 tracees where the setting disagrees between the two processes.\n\nFixes: 597ce1723e0f (\"MIPS: Support for 64-bit FP with O32 binaries\")\nSigned-off-by: Maciej W. Rozycki <macro@mips.com>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: linux-mips@linux-mips.org\nCc: <stable@vger.kernel.org> # 3.14+\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/f363b0cafb77370352d7943beccc8826cb3c8b2e"},{"sha":"bf8ac80fce8cf0affb0b004a470cdd92be9ae51e","author":{"name":"Colin Ian King","email":"d100aa70785e45ee8deab668147d941941915c21@canonical.com"},"message":"KVM: Fix spelling mistake: \"cop_unsuable\" -> \"cop_unusable\"\n\ncommit ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream.\n\nTrivial fix to spelling mistake in debugfs_entries text.\n\nFixes: 669e846e6c4e (\"KVM/MIPS32: MIPS arch specific APIs for KVM\")\nSigned-off-by: Colin Ian King <colin.king@canonical.com>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: linux-mips@linux-mips.org\nCc: kernel-janitors@vger.kernel.org\nCc: <stable@vger.kernel.org> # 3.10+\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/bf8ac80fce8cf0affb0b004a470cdd92be9ae51e"},{"sha":"4d21e6e82c43ca41a7b4ee12cea93e7a671865aa","author":{"name":"Al Viro","email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk"},"message":"affs_lookup(): close a race with affs_remove_link()\n\ncommit 30da870ce4a4e007c901858a96e9e394a1daa74a upstream.\n\nwe unlock the directory hash too early - if we are looking at secondary\nlink and primary (in another directory) gets removed just as we unlock,\nwe could have the old primary moved in place of the secondary, leaving\nus to look into freed entry (and leaving our dentry with ->d_fsdata\npointing to a freed entry).\n\nCc: stable@vger.kernel.org # 2.4.4+\nAcked-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/4d21e6e82c43ca41a7b4ee12cea93e7a671865aa"},{"sha":"1ac501e05fcd8a016d440c2d040272ab67f365b4","author":{"name":"Al Viro","email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk"},"message":"aio: fix io_destroy(2) vs. lookup_ioctx() race\n\ncommit baf10564fbb66ea222cae66fbff11c444590ffd9 upstream.\n\nkill_ioctx() used to have an explicit RCU delay between removing the\nreference from ->ioctx_table and percpu_ref_kill() dropping the refcount.\nAt some point that delay had been removed, on the theory that\npercpu_ref_kill() itself contained an RCU delay.  Unfortunately, that was\nthe wrong kind of RCU delay and it didn't care about rcu_read_lock() used\nby lookup_ioctx().  As the result, we could get ctx freed right under\nlookup_ioctx().  Tejun has fixed that in a6d7cff472e (\"fs/aio: Add explicit\nRCU grace period when freeing kioctx\"); however, that fix is not enough.\n\nSuppose io_destroy() from one thread races with e.g. io_setup() from another;\nCPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2\nhas picked it (under rcu_read_lock()).  Then CPU1 proceeds to drop the\nrefcount, getting it to 0 and triggering a call of free_ioctx_users(),\nwhich proceeds to drop the secondary refcount and once that reaches zero\ncalls free_ioctx_reqs().  That does\n        INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);\n        queue_rcu_work(system_wq, &ctx->free_rwork);\nand schedules freeing the whole thing after RCU delay.\n\nIn the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the\nrefcount from 0 to 1 and returned the reference to io_setup().\n\nTejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get\nfreed until after percpu_ref_get().  Sure, we'd increment the counter before\nctx can be freed.  Now we are out of rcu_read_lock() and there's nothing to\nstop freeing of the whole thing.  Unfortunately, CPU2 assumes that since it\nhas grabbed the reference, ctx is *NOT* going away until it gets around to\ndropping that reference.\n\nThe fix is obvious - use percpu_ref_tryget_live() and treat failure as miss.\nIt's not costlier than what we currently do in normal case, it's safe to\ncall since freeing *is* delayed and it closes the race window - either\nlookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users\nwon't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx()\nfails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see\nthe object in question at all.\n\nCc: stable@kernel.org\nFixes: a6d7cff472e \"fs/aio: Add explicit RCU grace period when freeing kioctx\"\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/1ac501e05fcd8a016d440c2d040272ab67f365b4"},{"sha":"c04a69fb83974aa25f1065fc0c7b63e046dc46f2","author":{"name":"Ben Hutchings","email":"a9aff6bdb06df0f1e86a184e2c263c6782eaee6c@codethink.co.uk"},"message":"ALSA: timer: Fix pause event notification\n\ncommit 3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.\n\nCommit f65e0d299807 (\"ALSA: timer: Call notifier in the same spinlock\")\ncombined the start/continue and stop/pause functions, and in doing so\nchanged the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE.\nChange it back to SNDRV_TIMER_EVENT_PAUSE.\n\nFixes: f65e0d299807 (\"ALSA: timer: Call notifier in the same spinlock\")\nSigned-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>\nCc: stable@vger.kernel.org\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/c04a69fb83974aa25f1065fc0c7b63e046dc46f2"},{"sha":"089440aa804c0e96b9b8442264dbea5179304125","author":{"name":"Corneliu Doban","email":"2336a77ec6251b339c592152e56c08dfca2caef5@broadcom.com"},"message":"mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register\n\ncommit 5f651b870485ee60f5abbbd85195a6852978894a upstream.\n\nWhen the host controller accepts only 32bit writes, the value of the\n16bit TRANSFER_MODE register, that has the same 32bit address as the\n16bit COMMAND register, needs to be saved and it will be written\nin a 32bit write together with the command as this will trigger the\nhost to send the command on the SD interface.\nWhen sending the tuning command, TRANSFER_MODE is written and then\nsdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and\nwrite it again resulting in wrong value to be written because the\ninitial write value was saved in a shadow and the read-back returned\na wrong value, from the register.\nFix sdhci_iproc_readw to return the saved value of TRANSFER_MODE\nwhen a saved value exist.\nSame fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are\nsaved for a different reason, although a scenario that will cause the\nmentioned problem on this registers is not probable.\n\nFixes: b580c52d58d9 (\"mmc: sdhci-iproc: add IPROC SDHCI driver\")\nSigned-off-by: Corneliu Doban <corneliu.doban@broadcom.com>\nSigned-off-by: Scott Branden <scott.branden@broadcom.com>\nCc: stable@vger.kernel.org # v4.1+\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/089440aa804c0e96b9b8442264dbea5179304125"},{"sha":"3b56232f54073dc83dffd441d23ee1bae4007f1a","author":{"name":"Tejun Heo","email":"546b05909706652891a87f7bfe385ae147f61f91@kernel.org"},"message":"libata: Blacklist some Sandisk SSDs for NCQ\n\ncommit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.\n\nSandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up\nregularly under sustained moderate load with NCQ enabled.  Blacklist\nfor now.\n\nSigned-off-by: Tejun Heo <tj@kernel.org>\nReported-by: Dave Jones <davej@codemonkey.org.uk>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/3b56232f54073dc83dffd441d23ee1bae4007f1a"},{"sha":"03d08c08041b949af7d4c9daefc17f5060cd3e3b","author":{"name":"Sudip Mukherjee","email":"551ae05ce198473af5b9da594240f54df5f81e31@gmail.com"},"message":"libata: blacklist Micron 500IT SSD with MU01 firmware\n\ncommit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.\n\nWhile whitelisting Micron M500DC drives, the tweaked blacklist entry\nenabled queued TRIM from M500IT variants also. But these do not support\nqueued TRIM. And while using those SSDs with the latest kernel we have\nseen errors and even the partition table getting corrupted.\n\nSome part from the dmesg:\n[    6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133\n[    6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA\n[    6.741026] ata1.00: supports DRM functions and may not be fully accessible\n[    6.759887] ata1.00: configured for UDMA/133\n[    6.762256] scsi 0:0:0:0: Direct-Access     ATA      Micron_M500IT_MT MU01 PQ: 0 ANSI: 5\n\nand then for the error:\n[  120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen\n[  120.860338] ata1.00: irq_stat 0x40000008\n[  120.860342] ata1.00: failed command: SEND FPDMA QUEUED\n[  120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out\n         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)\n[  120.860353] ata1.00: status: { DRDY }\n[  120.860543] ata1: hard resetting link\n[  121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)\n[  121.166376] ata1.00: supports DRM functions and may not be fully accessible\n[  121.186238] ata1.00: supports DRM functions and may not be fully accessible\n[  121.204445] ata1.00: configured for UDMA/133\n[  121.204454] ata1.00: device reported invalid CHS sector 0\n[  121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08\n[  121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]\n[  121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4\n[  121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00\n[  121.204559] print_req_error: I/O error, dev sda, sector 272512\n\nAfter few reboots with these errors, and the SSD is corrupted.\nAfter blacklisting it, the errors are not seen and the SSD does not get\ncorrupted any more.\n\nFixes: 243918be6393 (\"libata: Do not blacklist Micron M500DC\")\nCc: Martin K. Petersen <martin.petersen@oracle.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/03d08c08041b949af7d4c9daefc17f5060cd3e3b"},{"sha":"9de924517db0014e4377a665893624c2478ad6e3","author":{"name":"Joe Jin","email":"f057b23ea7478423ae110c031964105cfff9b6e7@oracle.com"},"message":"xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent\n\ncommit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.\n\nWhen run raidconfig from Dom0 we found that the Xen DMA heap is reduced,\nbut Dom Heap is increased by the same size. Tracing raidconfig we found\nthat the related ioctl() in megaraid_sas will call dma_alloc_coherent()\nto apply memory. If the memory allocated by Dom0 is not in the DMA area,\nit will exchange memory with Xen to meet the requiment. Later drivers\ncall dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()\nthe check condition (dev_addr + size - 1 <= dma_mask) is always false,\nit prevents calling xen_destroy_contiguous_region() to return the memory\nto the Xen DMA heap.\n\nThis issue introduced by commit 6810df88dcfc2 \"xen-swiotlb: When doing\ncoherent alloc/dealloc check before swizzling the MFNs.\".\n\nSigned-off-by: Joe Jin <joe.jin@oracle.com>\nTested-by: John Sobecki <john.sobecki@oracle.com>\nReviewed-by: Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/9de924517db0014e4377a665893624c2478ad6e3"},{"sha":"bd4792b31a8ebdfbb3a5af03a903ee8da1e78656","author":{"name":"Davidlohr Bueso","email":"bfcdf3e6ca6cef45543bfbb57509c92aec9a39fb@stgolabs.net"},"message":"Revert \"ipc/shm: Fix shmat mmap nil-page protection\"\n\ncommit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.\n\nPatch series \"ipc/shm: shmat() fixes around nil-page\".\n\nThese patches fix two issues reported[1] a while back by Joe and Andrea\naround how shmat(2) behaves with nil-page.\n\nThe first reverts a commit that it was incorrectly thought that mapping\nnil-page (address=0) was a no no with MAP_FIXED.  This is not the case,\nwith the exception of SHM_REMAP; which is address in the second patch.\n\nI chose two patches because it is easier to backport and it explicitly\nreverts bogus behaviour.  Both patches ought to be in -stable and ltp\ntestcases need updated (the added testcase around the cve can be\nmodified to just test for SHM_RND|SHM_REMAP).\n\n[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805\n\nThis patch (of 2):\n\nCommit 95e91b831f87 (\"ipc/shm: Fix shmat mmap nil-page protection\")\nworked on the idea that we should not be mapping as root addr=0 and\nMAP_FIXED.  However, it was reported that this scenario is in fact\nvalid, thus making the patch both bogus and breaks userspace as well.\n\nFor example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem\ninitialization[1].\n\n[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347\nLink: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net\nFixes: 95e91b831f87 (\"ipc/shm: Fix shmat mmap nil-page protection\")\nSigned-off-by: Davidlohr Bueso <dbueso@suse.de>\nReported-by: Joe Lawrence <joe.lawrence@redhat.com>\nReported-by: Andrea Arcangeli <aarcange@redhat.com>\nCc: Manfred Spraul <manfred@colorfullife.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/bd4792b31a8ebdfbb3a5af03a903ee8da1e78656"},{"sha":"a4e37ca958f179c24e814f3febfadcc2b3be105d","author":{"name":"Davidlohr Bueso","email":"bfcdf3e6ca6cef45543bfbb57509c92aec9a39fb@stgolabs.net"},"message":"ipc/shm: fix shmat() nil address after round-down when remapping\n\ncommit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.\n\nshmat()'s SHM_REMAP option forbids passing a nil address for; this is in\nfact the very first thing we check for.  Andrea reported that for\nSHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,\nbut we need to check again if the address was rounded down to nil.  As\nof this patch, such cases will return -EINVAL.\n\nLink: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805\nSigned-off-by: Davidlohr Bueso <dbueso@suse.de>\nReported-by: Andrea Arcangeli <aarcange@redhat.com>\nCc: Joe Lawrence <joe.lawrence@redhat.com>\nCc: Manfred Spraul <manfred@colorfullife.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/a4e37ca958f179c24e814f3febfadcc2b3be105d"},{"sha":"e6b2c060e0dfa8fc841feae5c9383fa96e5dc4ac","author":{"name":"David Hildenbrand","email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@redhat.com"},"message":"kasan: fix memory hotplug during boot\n\ncommit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.\n\nUsing module_init() is wrong.  E.g.  ACPI adds and onlines memory before\nour memory notifier gets registered.\n\nThis makes sure that ACPI memory detected during boot up will not result\nin a kernel crash.\n\nEasily reproducible with QEMU, just specify a DIMM when starting up.\n\nLink: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com\nFixes: 786a8959912e (\"kasan: disable memory hotplug\")\nSigned-off-by: David Hildenbrand <david@redhat.com>\nAcked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>\nCc: Alexander Potapenko <glider@google.com>\nCc: Dmitry Vyukov <dvyukov@google.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/e6b2c060e0dfa8fc841feae5c9383fa96e5dc4ac"},{"sha":"34dedd5d7bb9f5e798a0d4ab882a64e8b8a9720f","author":{"name":"Gustavo A. R. Silva","email":"beac5f8171fcde5e2ec734cc5d25d03e7362e8de@embeddedor.com"},"message":"kernel/sys.c: fix potential Spectre v1 issue\n\ncommit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.\n\n`resource' can be controlled by user-space, hence leading to a potential\nexploitation of the Spectre variant 1 vulnerability.\n\nThis issue was detected with the help of Smatch:\n\n  kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)\n  kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)\n\nFix this by sanitizing *resource* before using it to index\ncurrent->signal->rlim\n\nNotice that given that speculation windows are large, the policy is to\nkill the speculation on the first load and not worry if it can be\ncompleted with a dependent load/store [1].\n\n[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2\n\nLink: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com\nSigned-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Alexei Starovoitov <ast@kernel.org>\nCc: Dan Williams <dan.j.williams@intel.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/34dedd5d7bb9f5e798a0d4ab882a64e8b8a9720f"},{"sha":"cb1c92e55420dad73ce717ef4029dd6e984dcbd0","author":{"name":"zhongjiang","email":"e00b852f945f8ed516726e617fc62ab2ed3a16a5@huawei.com"},"message":"kernel/signal.c: avoid undefined behaviour in kill_something_info\n\ncommit 4ea77014af0d6205b05503d1c7aac6eace11d473 upstream.\n\nWhen running kill(72057458746458112, 0) in userspace I hit the following\nissue.\n\n  UBSAN: Undefined behaviour in kernel/signal.c:1462:11\n  negation of -2147483648 cannot be represented in type 'int':\n  CPU: 226 PID: 9849 Comm: test Tainted: G    B          ---- -------   3.10.0-327.53.58.70.x86_64_ubsan+ #116\n  Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014\n  Call Trace:\n    dump_stack+0x19/0x1b\n    ubsan_epilogue+0xd/0x50\n    __ubsan_handle_negate_overflow+0x109/0x14e\n    SYSC_kill+0x43e/0x4d0\n    SyS_kill+0xe/0x10\n    system_call_fastpath+0x16/0x1b\n\nAdd code to avoid the UBSAN detection.\n\n[akpm@linux-foundation.org: tweak comment]\nLink: http://lkml.kernel.org/r/1496670008-59084-1-git-send-email-zhongjiang@huawei.com\nSigned-off-by: zhongjiang <zhongjiang@huawei.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: Michal Hocko <mhocko@kernel.org>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Xishi Qiu <qiuxishi@huawei.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Guenter Roeck <linux@roeck-us.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/cb1c92e55420dad73ce717ef4029dd6e984dcbd0"},{"sha":"1a54258e10b23c6877d699ef6cf3f2b02b17b87f","author":{"name":"Brian Foster","email":"335646b5e374a776a6a2caca10969d6e3ec1cd2b@redhat.com"},"message":"xfs: remove racy hasattr check from attr ops\n\ncommit 5a93790d4e2df73e30c965ec6e49be82fc3ccfce upstream.\n\nxfs_attr_[get|remove]() have unlocked attribute fork checks to optimize\naway a lock cycle in cases where the fork does not exist or is otherwise\nempty. This check is not safe, however, because an attribute fork short\nform to extent format conversion includes a transient state that causes\nthe xfs_inode_hasattr() check to fail. Specifically,\nxfs_attr_shortform_to_leaf() creates an empty extent format attribute\nfork and then adds the existing shortform attributes to it.\n\nThis means that lookup of an existing xattr can spuriously return\n-ENOATTR when racing against a setxattr that causes the associated\nformat conversion. This was originally reproduced by an untar on a\nparticularly configured glusterfs volume, but can also be reproduced on\ndemand with properly crafted xattr requests.\n\nThe format conversion occurs under the exclusive ilock. xfs_attr_get()\nand xfs_attr_remove() already have the proper locking and checks further\ndown in the functions to handle this situation correctly. Drop the\nunlocked checks to avoid the spurious failure and rely on the existing\nlogic.\n\nSigned-off-by: Brian Foster <bfoster@redhat.com>\nReviewed-by: Christoph Hellwig <hch@lst.de>\nReviewed-by: Darrick J. Wong <darrick.wong@oracle.com>\nSigned-off-by: Darrick J. Wong <darrick.wong@oracle.com>\nCc: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/1a54258e10b23c6877d699ef6cf3f2b02b17b87f"},{"sha":"03bb7588942a38623f108b3302c2d1aebb525696","author":{"name":"Al Viro","email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk"},"message":"do d_instantiate/unlock_new_inode combinations safely\n\ncommit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.\n\nFor anything NFS-exported we do _not_ want to unlock new inode\nbefore it has grown an alias; original set of fixes got the\nordering right, but missed the nasty complication in case of\nlockdep being enabled - unlock_new_inode() does\n\tlockdep_annotate_inode_mutex_key(inode)\nwhich can only be done before anyone gets a chance to touch\n->i_mutex.  Unfortunately, flipping the order and doing\nunlock_new_inode() before d_instantiate() opens a window when\nmkdir can race with open-by-fhandle on a guessed fhandle, leading\nto multiple aliases for a directory inode and all the breakage\nthat follows from that.\n\n\tCorrect solution: a new primitive (d_instantiate_new())\ncombining these two in the right order - lockdep annotate, then\nd_instantiate(), then the rest of unlock_new_inode().  All\ncombinations of d_instantiate() with unlock_new_inode() should\nbe converted to that.\n\nCc: stable@kernel.org\t# 2.6.29 and later\nTested-by: Mike Marshall <hubcap@omnibond.com>\nReviewed-by: Andreas Dilger <adilger@dilger.ca>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/03bb7588942a38623f108b3302c2d1aebb525696"},{"sha":"fc66e3f87a36d2b84a8d86ea9e5dd4d2b96fe830","author":{"name":"Hector Martin","email":"d12eb697b718156ba255408722460a103b2f179c@marcan.st"},"message":"firewire-ohci: work around oversized DMA reads on JMicron controllers\n\n[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]\n\nAt least some JMicron controllers issue buggy oversized DMA reads when\nfetching context descriptors, always fetching 0x20 bytes at once for\ndescriptors which are only 0x10 bytes long. This is often harmless, but\ncan cause page faults on modern systems with IOMMUs:\n\nDMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set\nfirewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read\n\nThis works around the problem by always leaving 0x10 padding bytes at\nthe end of descriptor buffer pages, which should be harmless to do\nunconditionally for controllers in case others have the same behavior.\n\nSigned-off-by: Hector Martin <marcan@marcan.st>\nReviewed-by: Clemens Ladisch <clemens@ladisch.de>\nSigned-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/fc66e3f87a36d2b84a8d86ea9e5dd4d2b96fe830"},{"sha":"608848f0a62d45809bf82f7b5a8eb400e620901d","author":{"name":"NeilBrown","email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.com"},"message":"NFSv4: always set NFS_LOCK_LOST when a lock is lost.\n\n[ Upstream commit dce2630c7da73b0634686bca557cc8945cc450c8 ]\n\nThere are 2 comments in the NFSv4 code which suggest that\nSIGLOST should possibly be sent to a process.  In these\ncases a lock has been lost.\nThe current practice is to set NFS_LOCK_LOST so that\nread/write returns EIO when a lock is lost.\nSo change these comments to code when sets NFS_LOCK_LOST.\n\nOne case is when lock recovery after apparent server restart\nfails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or\nNFS4ERRO_RECLAIM_CONFLICT.  The other case is when a lock\nattempt as part of lease recovery fails with NFS4ERR_DENIED.\n\nIn an ideal world, these should not happen.  However I have\na packet trace showing an NFSv4.1 session getting\nNFS4ERR_BADSESSION after an extended network parition.  The\nNFSv4.1 client treats this like server reboot until/unless\nit get NFS4ERR_NO_GRACE, in which case it switches over to\n\"nograce\" recovery mode.  In this network trace, the client\nattempts to recover a lock and the server (incorrectly)\nreports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE.  This\nleads to the ineffective comment and the client then\ncontinues to write using the OPEN stateid.\n\nSigned-off-by: NeilBrown <neilb@suse.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/608848f0a62d45809bf82f7b5a8eb400e620901d"},{"sha":"4281754e6bea7ee49e08c231096c2668deaa5ac8","author":{"name":"Takashi Iwai","email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de"},"message":"ALSA: hda - Use IS_REACHABLE() for dependency on input\n\n[ Upstream commit c469652bb5e8fb715db7d152f46d33b3740c9b87 ]\n\nThe commit ffcd28d88e4f (\"ALSA: hda - Select INPUT for Realtek\nHD-audio codec\") introduced the reverse-selection of CONFIG_INPUT for\nRealtek codec in order to avoid the mess with dependency between\nbuilt-in and modules.  Later on, we obtained IS_REACHABLE() macro\nexactly for this kind of problems, and now we can remove th INPUT\nselection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate\nplaces in the code, so that the driver doesn't need to select other\nsubsystem forcibly.\n\nFixes: ffcd28d88e4f (\"ALSA: hda - Select INPUT for Realtek HD-audio codec\")\nReported-by: Randy Dunlap <rdunlap@infradead.org>\nAcked-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_motorola_msm8998/commits/4281754e6bea7ee49e08c231096c2668deaa5ac8"}]}
{"actor":{"display_login":"DirtyUnicorn"}}