{"push_id":1099846193,"size":202,"distinct_size":0,"ref":"refs/heads/grsec-4.5","head":"3672afb4e4f41b42799301c39a61fd7a36b1c81e","before":"1ffeae15c7ef6df295392700d8581b4fcece0b9e","commits":[{"sha":"58821da858919f93f85c7e6823b49d439722a9e9","author":{"email":"fe47b31f388f85ce6ddf64bf3a0cf6b46077d0e6@linaro.org","name":"Ulf Hansson"},"message":"mmc: block: Use the mmc host device index as the mmcblk device index\n\ncommit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d upstream.\n\nCommit 520bd7a8b415 (\"mmc: core: Optimize boot time by detecting cards\nsimultaneously\") causes regressions for some platforms.\n\nThese platforms relies on fixed mmcblk device indexes, instead of\ndeploying the defacto standard with UUID/PARTUUID. In other words their\nrootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.\n\nSuch guarantees have never been made by the kernel, but clearly the above\ncommit changes the behaviour. More precisely, because of that the order\nchanges of how cards becomes detected, so do their corresponding mmcblk\ndevice indexes.\n\nAs the above commit significantly improves boot time for some platforms\n(magnitude of seconds), let's avoid reverting this change but instead\nrestore the behaviour of how mmcblk device indexes becomes picked.\n\nBy using the same index for the mmcblk device as for the corresponding mmc\nhost device, the probe order of mmc host devices decides the index we get\nfor the mmcblk device.\n\nFor those platforms that suffers from a regression, one could expect that\nthis updated behaviour should be sufficient to meet their expectations of\n\"fixed\" mmcblk device indexes.\n\nAnother side effect from this change, is that the same index is used for\nthe mmc host device, the mmcblk device and the mmc block queue. That\nshould clarify their relationship.\n\nReported-by: Peter Hurley <peter@hurleysoftware.com>\nReported-by: Laszlo Fiat <laszlo.fiat@gmail.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nFixes: 520bd7a8b415 (\"mmc: core: Optimize boot time by detecting cards\nsimultaneously\")\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/58821da858919f93f85c7e6823b49d439722a9e9"},{"sha":"abe7c54ffae585e09df500aa310a992b2fb41dc8","author":{"email":"8d0fc11caeb4659419f0ba3104eb4a9d30848d42@canonical.com","name":"Ming Lei"},"message":"block: partition: initialize percpuref before sending out KOBJ_ADD\n\ncommit b30a337ca27c4f40439e4bfb290cba5f88d73bb7 upstream.\n\nThe initialization of partition's percpu_ref should have been done before\nsending out KOBJ_ADD uevent, which may cause userspace to read partition\ntable. So the uninitialized percpu_ref may be accessed in data path.\n\nThis patch fixes this issue reported by Naveen.\n\nReported-by: Naveen Kaje <nkaje@codeaurora.org>\nTested-by: Naveen Kaje <nkaje@codeaurora.org>\nFixes: 6c71013ecb7e2(block: partition: convert percpu ref)\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/abe7c54ffae585e09df500aa310a992b2fb41dc8"},{"sha":"3e0deff056c7ae5e868b8602ce887e98b943a181","author":{"email":"8d0fc11caeb4659419f0ba3104eb4a9d30848d42@canonical.com","name":"Ming Lei"},"message":"block: loop: fix filesystem corruption in case of aio/dio\n\ncommit a7297a6a3a3322b054592e8e988981d2f5f29cc4 upstream.\n\nStarting from commit e36f620428(block: split bios to max possible length),\nblock core starts to split bio in the middle of bvec.\n\nUnfortunately loop dio/aio doesn't consider this situation, and\nalways treat 'iter.iov_offset' as zero. Then filesystem corruption\nis observed.\n\nThis patch figures out the offset of the base bvevc via\n'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset\nto iov iterator.\n\nFixes: e36f6204288088f (block: split bios to max possible length)\nCc: Keith Busch <keith.busch@intel.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/3e0deff056c7ae5e868b8602ce887e98b943a181"},{"sha":"7da29dd44f0240c6b52bacaed5cbf05c2b172364","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping\n\ncommit 7cc8cbcf82d165dd658d89a7a287140948e76413 upstream.\n\nCommit 4dffbfc48d65 (\"arm64/efi: mark UEFI reserved regions as\nMEMBLOCK_NOMAP\") updated the mapping logic of both the RuntimeServices\nregions as well as the kernel's copy of the UEFI memory map to set the\nMEMBLOCK_NOMAP flag, which causes these regions to be omitted from the\nkernel direct mapping, and from being covered by a struct page.\nFor the RuntimeServices regions, this is an obvious win, since the contents\nof these regions have significance to the firmware executable code itself,\nand are mapped in the EFI page tables using attributes that are described in\nthe UEFI memory map, and which may differ from the attributes we use for\nmapping system RAM. It also prevents the contents from being modified\ninadvertently, since the EFI page tables are only live during runtime\nservice invocations.\n\nNone of these concerns apply to the allocation that covers the UEFI memory\nmap, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on\nthe region did allow us to use ioremap_cache() to map it both on arm64 and\non ARM, since the latter does not allow ioremap_cache() to be used on\nregions that are covered by a struct page.\n\nThe ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe,\nbut in the mean time, it has been reported that commit 4dffbfc48d65 causes\na regression on 64k granule kernels. This is due to the fact that, given\nthe 64 KB page size, the region that we end up removing from the kernel\ndirect mapping is rounded up to 64 KB, and this 64 KB page frame may be\nshared with the initrd when booting via GRUB (which does not align its\nEFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash\nthe kernel as soon as it tries to access the initrd.\n\nSince the issue is specific to arm64, revert back to memblock_reserve()'ing\nthe UEFI memory map when running on arm64. This is a temporary fix for v4.5\nand v4.6, and will be superseded in the v4.7 timeframe when we will be able\nto move back to memblock_reserve() unconditionally.\n\nFixes: 4dffbfc48d65 (\"arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP\")\nReported-by: Mark Salter <msalter@redhat.com>\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Will Deacon <will.deacon@arm.com>\nCc: Leif Lindholm <leif.lindholm@linaro.org>\nCc: Mark Rutland <mark.rutland@arm.com>\nCc: Jeremy Linton <jeremy.linton@arm.com>\nCc: Mark Langsdorf <mlangsdo@redhat.com>\nSigned-off-by: Matt Fleming <matt@codeblueprint.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/7da29dd44f0240c6b52bacaed5cbf05c2b172364"},{"sha":"065b9de35b34f83af8a9391b1277f26bb351363d","author":{"email":"e7984595ec0368ff920a7b3521dc7093683f6f26@intel.com","name":"Tony Luck"},"message":"x86/mce: Avoid using object after free in genpool\n\ncommit a3125494cff084b098c80bb36fbe2061ffed9d52 upstream.\n\nWhen we loop over all queued machine check error records to pass them\nto the registered notifiers we use llist_for_each_entry(). But the loop\ncalls gen_pool_free() for the entry in the body of the loop - and then\nthe iterator looks at node->next after the free.\n\nUse llist_for_each_entry_safe() instead.\n\nSigned-off-by: Tony Luck <tony.luck@intel.com>\nSigned-off-by: Borislav Petkov <bp@suse.de>\nCc: Gong Chen <gong.chen@linux.intel.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-edac <linux-edac@vger.kernel.org>\nLink: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com\nLink: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.de\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/065b9de35b34f83af8a9391b1277f26bb351363d"},{"sha":"f99c7c1717f997db1ae89f6a14809f1312caeb3d","author":{"email":"af3a1abb318f80516a89043d3cf305795fb8380c@google.com","name":"David Matlack"},"message":"kvm: x86: do not leak guest xcr0 into host interrupt handlers\n\ncommit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 upstream.\n\nAn interrupt handler that uses the fpu can kill a KVM VM, if it runs\nunder the following conditions:\n - the guest's xcr0 register is loaded on the cpu\n - the guest's fpu context is not loaded\n - the host is using eagerfpu\n\nNote that the guest's xcr0 register and fpu context are not loaded as\npart of the atomic world switch into \"guest mode\". They are loaded by\nKVM while the cpu is still in \"host mode\".\n\nUsage of the fpu in interrupt context is gated by irq_fpu_usable(). The\ninterrupt handler will look something like this:\n\nif (irq_fpu_usable()) {\n        kernel_fpu_begin();\n\n        [... code that uses the fpu ...]\n\n        kernel_fpu_end();\n}\n\nAs long as the guest's fpu is not loaded and the host is using eager\nfpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()\nreturns true). The interrupt handler proceeds to use the fpu with\nthe guest's xcr0 live.\n\nkernel_fpu_begin() saves the current fpu context. If this uses\nXSAVE[OPT], it may leave the xsave area in an undesirable state.\nAccording to the SDM, during XSAVE bit i of XSTATE_BV is not modified\nif bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and\nxcr0[i] == 0 following an XSAVE.\n\nkernel_fpu_end() restores the fpu context. Now if any bit i in\nXSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The\nfault is trapped and SIGSEGV is delivered to the current process.\n\nOnly pre-4.2 kernels appear to be vulnerable to this sequence of\nevents. Commit 653f52c (\"kvm,x86: load guest FPU context more eagerly\")\nfrom 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.\n\nThis patch fixes the bug by keeping the host's xcr0 loaded outside\nof the interrupts-disabled region where KVM switches into guest mode.\n\nSuggested-by: Andy Lutomirski <luto@amacapital.net>\nSigned-off-by: David Matlack <dmatlack@google.com>\n[Move load after goto cancel_injection. - Paolo]\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/f99c7c1717f997db1ae89f6a14809f1312caeb3d"},{"sha":"dfcaf5d7f967678a6edf08139886c2e1c462bbcf","author":{"email":"a16cc0c82647c52d401177f8e50567df5499e36c@arm.com","name":"Marc Zyngier"},"message":"KVM: arm/arm64: Handle forward time correction gracefully\n\ncommit 1c5631c73fc2261a5df64a72c155cb53dcdc0c45 upstream.\n\nOn a host that runs NTP, corrections can have a direct impact on\nthe background timer that we program on the behalf of a vcpu.\n\nIn particular, NTP performing a forward correction will result in\na timer expiring sooner than expected from a guest point of view.\nNot a big deal, we kick the vcpu anyway.\n\nBut on wake-up, the vcpu thread is going to perform a check to\nfind out whether or not it should block. And at that point, the\ntimer check is going to say \"timer has not expired yet, go back\nto sleep\". This results in the timer event being lost forever.\n\nThere are multiple ways to handle this. One would be record that\nthe timer has expired and let kvm_cpu_has_pending_timer return\ntrue in that case, but that would be fairly invasive. Another is\nto check for the \"short sleep\" condition in the hrtimer callback,\nand restart the timer for the remaining time when the condition\nis detected.\n\nThis patch implements the latter, with a bit of refactoring in\norder to avoid too much code duplication.\n\nReported-by: Alexander Graf <agraf@suse.de>\nReviewed-by: Alexander Graf <agraf@suse.de>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/dfcaf5d7f967678a6edf08139886c2e1c462bbcf"},{"sha":"c8b266e2fa59586a085caf9f50217e2e6e4b2659","author":{"email":"c1574519d727edaf2e16b260e452051ef77bf018@ti.com","name":"Lokesh Vutla"},"message":"ARM: dts: AM43x-epos: Fix clk parent for synctimer\n\ncommit cfe1580a6415bc37fd62d79eb8102a618f7650b2 upstream.\n\ncommit 55ee7017ee31 (\"arm: omap2: board-generic: use omap4_local_timer_init\nfor AM437x\") makes synctimer32k as the clocksource on AM43xx. By default\nthe synctimer32k is clocked by 32K RTC OSC on AM43xx. But this 32K RTC OSC\nis not available on epos boards which makes it fail to boot.\n\nSynctimer32k can also be clocked by a peripheral PLL, so making this as\nclock parent for synctimer3k on epos boards.\n\nFixes: 55ee7017ee31 (\"arm: omap2: board-generic: use omap4_local_timer_init for AM437x\")\nReported-by: Nishanth Menon <nm@ti.com>\nSigned-off-by: Lokesh Vutla <lokeshvutla@ti.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/c8b266e2fa59586a085caf9f50217e2e6e4b2659"},{"sha":"4984953d536352b1d665edb9039ca311931622af","author":{"email":"060a12f1fbc7e2e5d830b72f402ff04fdae8d312@ti.com","name":"Tero Kristo"},"message":"ARM: dts: am43xx: fix edma memcpy channel allocation\n\ncommit d41676ddddef27224a398609d874055866694cfa upstream.\n\nEDMA was allocating DMA channels 32 and 33 for memcpy usage, out of which\nchannel 33 is actually used by DES crypto engine. This bad allocation of\nthe channel causes a crash in the DES crypto engine, as the channel\ngets configured for memcpy usage instead of hardware <-> memory DMA.\n\nFixed by allocating DMA channels 58 and 59 for memcpy usage (I2C0 RX/TX),\nwhich are not used by anybody.\n\nFixes: cce1ee000187 (\"ARM: DTS: am437x: Use the new DT bindings for\nthe eDMA3\")\nSigned-off-by: Tero Kristo <t-kristo@ti.com>\nSuggested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/4984953d536352b1d665edb9039ca311931622af"},{"sha":"786590668743ca69ece4f8090f2f6e76e9abe18a","author":{"email":"cbb7353e6d953ef360baf960c122346276c6e320@puiterwijk.org","name":"Patrick Uiterwijk"},"message":"ARM: mvebu: Correct unit address for linksys\n\ncommit 199831c77c50e6913e893b6bc268ba9f4a9a2bf8 upstream.\n\nThe USB2 port for Armada 38x is defined to be at 58000, not at\n50000.\n\nFixes: 2d0a7addbd10 (\"ARM: Kirkwood: Add support for many Synology NAS devices\")\nSigned-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>\nAcked-by: Imre Kaloz <kaloz@openwrt.org>\nSigned-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/786590668743ca69ece4f8090f2f6e76e9abe18a"},{"sha":"66d268b43751cdf5717173c32713db6636edba9e","author":{"email":"50c3c575ce2bb12c45e20736ce59e86fe81915b4@ti.com","name":"Nishanth Menon"},"message":"ARM: OMAP2: Fix up interconnect barrier initialization for DRA7\n\ncommit 456e8d53482537616899a146b706eccd095404e6 upstream.\n\nThe following commits:\ncommit 3fa609755c11 (\"ARM: omap2: restore OMAP4 barrier behaviour\")\ncommit f746929ffdc8 (\"Revert \"ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688\"\")\nand\ncommit ea827ad5ffbb (\"ARM: DRA7: Provide proper IO map table\")\ncame in around the same time, unfortunately this seem to have missed\ninitializing the barrier for DRA7 platforms - omap5_map_io was reused\nfor dra7 till it was split out by the last patch. barrier_init\nneeds to be hence carried forward as it is valid for DRA7 family of\nprocessors as they are for OMAP5.\n\nFixes: ea827ad5ffbb7 (\"ARM: DRA7: Provide proper IO map table\")\nReported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nReported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>\nCc: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Nishanth Menon <nm@ti.com>\nReviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/66d268b43751cdf5717173c32713db6636edba9e"},{"sha":"459c0dc452b63bb22708ffd2235bbb794b912992","author":{"email":"c1574519d727edaf2e16b260e452051ef77bf018@ti.com","name":"Lokesh Vutla"},"message":"ARM: OMAP2+: hwmod: Fix updating of sysconfig register\n\ncommit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream.\n\nCommit 127500ccb766f (\"ARM: OMAP2+: Only write the sysconfig on idle\nwhen necessary\") talks about verification of sysconfig cache value before\nupdating it, only during idle path. But the patch is adding the\nverification in the enable path. So, adding the check in a proper place\nas per the commit description.\n\nNot keeping this check during enable path as there is a chance of losing\ncontext and it is safe to do on idle as the context of the register will\nnever be lost while the device is active.\n\nSigned-off-by: Lokesh Vutla <lokeshvutla@ti.com>\nAcked-by: Tero Kristo <t-kristo@ti.com>\nCc: Jon Hunter <jonathanh@nvidia.com>\nFixes: commit 127500ccb766 \"ARM: OMAP2+: Only write the sysconfig on idle when necessary\"\n[paul@pwsan.com: appears to have been caused by my own mismerge of the\n originally posted patch]\nSigned-off-by: Paul Walmsley <paul@pwsan.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/459c0dc452b63bb22708ffd2235bbb794b912992"},{"sha":"3a8c16abfa42e287b586142297115986b8eeb8fb","author":{"email":"d3643b417d7bb29446cdadf5ebe2f94cac95db45@redhat.com","name":"Jerome Marchand"},"message":"assoc_array: don't call compare_object() on a node\n\ncommit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream.\n\nChanges since V1: fixed the description and added KASan warning.\n\nIn assoc_array_insert_into_terminal_node(), we call the\ncompare_object() method on all non-empty slots, even when they're\nnot leaves, passing a pointer to an unexpected structure to\ncompare_object(). Currently it causes an out-of-bound read access\nin keyring_compare_object detected by KASan (see below). The issue\nis easily reproduced with keyutils testsuite.\nOnly call compare_object() when the slot is a leave.\n\nKASan warning:\n==================================================================\nBUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838\nRead of size 8 by task keyctl/1655\n=============================================================================\nBUG kmalloc-192 (Not tainted): kasan: bad access detected\n-----------------------------------------------------------------------------\n\nDisabling lock debugging due to kernel taint\nINFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647\n\t___slab_alloc+0x563/0x5c0\n\t__slab_alloc+0x51/0x90\n\tkmem_cache_alloc_trace+0x263/0x300\n\tassoc_array_insert+0xfd0/0x3a60\n\t__key_link_begin+0xfc/0x270\n\tkey_create_or_update+0x459/0xaf0\n\tSyS_add_key+0x1ba/0x350\n\tentry_SYSCALL_64_fastpath+0x12/0x76\nINFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080\nINFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1\n\nBytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............\nObject ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....\nObject ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nCPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491\n ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969\n ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650\nCall Trace:\n [<ffffffff81b60491>] dump_stack+0x85/0xc4\n [<ffffffff815e2969>] print_trailer+0xf9/0x150\n [<ffffffff815e9454>] object_err+0x34/0x40\n [<ffffffff815ebe50>] kasan_report_error+0x230/0x550\n [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210\n [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70\n [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240\n [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240\n [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60\n [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70\n [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270\n [<ffffffff8199786c>] __key_link_begin+0xfc/0x270\n [<ffffffff81993389>] key_create_or_update+0x459/0xaf0\n [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10\n [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0\n [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0\n [<ffffffff81534763>] ? memdup_user+0x53/0x80\n [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350\n [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0\n [<ffffffff828bcf4e>] ? retint_user+0x18/0x23\n [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580\n [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19\n [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76\nMemory state around the buggy address:\n ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00\n ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc\n>ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                                        ^\n ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00\n==================================================================\n\nSigned-off-by: Jerome Marchand <jmarchan@redhat.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/3a8c16abfa42e287b586142297115986b8eeb8fb"},{"sha":"8547d83761dfc36e24c86116a57708ae65c8cd24","author":{"email":"f66f867dbd8b5577c23781552a3f5577f8093dfe@intel.com","name":"Rafal Redzimski"},"message":"usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host\n\ncommit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream.\n\nBroxton B0 also requires XHCI_PME_STUCK_QUIRK.\nAdding PCI device ID for Broxton B and adding to quirk.\n\nSigned-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>\nSigned-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/8547d83761dfc36e24c86116a57708ae65c8cd24"},{"sha":"39af3586b3c217db185c26f49b24b756579ea663","author":{"email":"2d4473c5e67eb83655334d4e9a7757f781607241@linux.intel.com","name":"Mathias Nyman"},"message":"xhci: resume USB 3 roothub first\n\ncommit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 upstream.\n\nGive USB3 devices a better chance to enumerate at USB 3 speeds if\nthey are connected to a suspended host.\nSolves an issue with NEC uPD720200 host hanging when partially\nenumerating a USB3 device as USB2 after host controller runtime resume.\n\nTested-by: Mike Murdoch <main.haarp@gmail.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/39af3586b3c217db185c26f49b24b756579ea663"},{"sha":"93e64310a349d390b7fd1e38ebdc88c6eb76e6b4","author":{"email":"de6fb888308c49c20838826baf4e7cc406af80ff@renesas.com","name":"Yoshihiro Shimoda"},"message":"usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT\n\ncommit 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 upstream.\n\nOn some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of\nHCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit\naddress memory pointers actually. So, in this case, this driver should\ncall dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().\nOtherwise, the xHCI controller will be died after a usb device is\nconnected if it runs on above 4GB physical memory environment.\n\nSo, this patch adds a new quirk XHCI_NO_64BIT_SUPPORT to resolve\nsuch an issue.\n\nSigned-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>\nReviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/93e64310a349d390b7fd1e38ebdc88c6eb76e6b4"},{"sha":"cdefb5685abbea5c75b62e38cac5bcde799886eb","author":{"email":"de6fb888308c49c20838826baf4e7cc406af80ff@renesas.com","name":"Yoshihiro Shimoda"},"message":"usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys\n\ncommit 5ad3b03e4910f9f62342956ecdc758c7af6b8699 upstream.\n\nThis patch fixes an issue that cannot work if R-Car Gen2/3 run on\nabove 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT.\n\nSigned-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>\nReviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/cdefb5685abbea5c75b62e38cac5bcde799886eb"},{"sha":"46810b1c030ec57830a9939d677bca26c5131451","author":{"email":"0e8503a5d55e00d5d2190cff62ef5fd449aa2247@linux.intel.com","name":"Lu Baolu"},"message":"usb: xhci: fix wild pointers in xhci_mem_cleanup\n\ncommit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.\n\nThis patch fixes some wild pointers produced by xhci_mem_cleanup.\nThese wild pointers will cause system crash if xhci_mem_cleanup()\nis called twice.\n\nReported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>\nSigned-off-by: Lu Baolu <baolu.lu@linux.intel.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/46810b1c030ec57830a9939d677bca26c5131451"},{"sha":"7786c2f1ffb5e64ec7f7678b6f0f5ac4cbbf45f9","author":{"email":"2d4473c5e67eb83655334d4e9a7757f781607241@linux.intel.com","name":"Mathias Nyman"},"message":"xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers\n\ncommit 98d74f9ceaefc2b6c4a6440050163a83be0abede upstream.\n\nPCI hotpluggable xhci controllers such as some Alpine Ridge solutions will\nremove the xhci controller from the PCI bus when the last USB device is\ndisconnected.\n\nAdd a flag to indicate that the host is being removed to avoid queueing\nconfigure_endpoint commands for the dropped endpoints.\nFor PCI hotplugged controllers this will prevent 5 second command timeouts\nFor static xhci controllers the configure_endpoint command is not needed\nin the removal case as everything will be returned, freed, and the\ncontroller is reset.\n\nFor now the flag is only set for PCI connected host controllers.\n\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/7786c2f1ffb5e64ec7f7678b6f0f5ac4cbbf45f9"},{"sha":"d3a0db2a8acb66545c1648b19f9fef419c5fb1d0","author":{"email":"82f81e62be2bf153f8e7977fe8d5e19723573a1d@linaro.org","name":"Peter Griffin"},"message":"usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value\n\ncommit f9a85f6e61c695daeb427dfc6c1d5a279654207b upstream.\n\nOtherwise generic-xhci and xhci-platform which have no data get wrongly\ndetected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().\n\nThis fixes a regression in v4.5 for STiH407 family SoC's which use the\nsynopsis dwc3 IP, whereby the disable_clk error path gets taken due to\nwrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never\ngets added.\n\nI suspect this will also fix other dwc3 DT platforms such as Exynos,\nalthough I've only tested on STih410 SoC.\n\nFixes: 4efb2f694114 (\"usb: host: xhci-plat: add struct xhci_plat_priv\")\nCc: gregory.clement@free-electrons.com\nCc: yoshihiro.shimoda.uh@renesas.com\nSigned-off-by: Peter Griffin <peter.griffin@linaro.org>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/linux-scraping/linux-grsecurity/commits/d3a0db2a8acb66545c1648b19f9fef419c5fb1d0"}]}