{"push_id":1156541858,"size":24,"distinct_size":24,"ref":"refs/heads/korg/linux-3.14.y","head":"022aafd04696a3c6b7ad47ab83a9650646287bf8","before":"f06cb456a442c7df95a4ba6e2f3a341cf925d7cf","commits":[{"sha":"7cb989736793d76c12b02f796143668fa0e7209b","author":{"name":"Paul Burton","email":"6cf344976ede6e423f0f16c3121262bddc8fed82@imgtec.com"},"message":"MIPS: math-emu: Fix jalr emulation when rd == $0\n\ncommit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream.\n\nWhen emulating a jalr instruction with rd == $0, the code in\nisBranchInstr was incorrectly writing to GPR $0 which should actually\nalways remain zeroed. This would lead to any further instructions\nemulated which use $0 operating on a bogus value until the task is next\ncontext switched, at which point the value of $0 in the task context\nwould be restored to the correct zero by a store in SAVE_SOME. Fix this\nby not writing to rd if it is $0.\n\nFixes: 102cedc32a6e (\"MIPS: microMIPS: Floating point support.\")\nSigned-off-by: Paul Burton <paul.burton@imgtec.com>\nCc: Maciej W. Rozycki <macro@imgtec.com>\nCc: James Hogan <james.hogan@imgtec.com>\nCc: linux-mips@linux-mips.org\nCc: linux-kernel@vger.kernel.org\nPatchwork: https://patchwork.linux-mips.org/patch/13160/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/7cb989736793d76c12b02f796143668fa0e7209b"},{"sha":"29fe292d71888470662f298e28501c34c548693e","author":{"name":"James Hogan","email":"00935fde11ed589f6e5a2cfc70182e355d2baa37@imgtec.com"},"message":"MIPS: Fix siginfo.h to use strict posix types\n\ncommit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.\n\nCommit 85efde6f4e0d (\"make exported headers use strict posix types\")\nchanged the asm-generic siginfo.h to use the __kernel_* types, and\ncommit 3a471cbc081b (\"remove __KERNEL_STRICT_NAMES\") make the internal\ntypes accessible only to the kernel, but the MIPS implementation hasn't\nbeen updated to match.\n\nSwitch to proper types now so that the exported asm/siginfo.h won't\nproduce quite so many compiler errors when included alone by a user\nprogram.\n\nSigned-off-by: James Hogan <james.hogan@imgtec.com>\nCc: Christopher Ferris <cferris@google.com>\nCc: linux-mips@linux-mips.org\nCc: linux-kernel@vger.kernel.org\nPatchwork: https://patchwork.linux-mips.org/patch/12477/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/29fe292d71888470662f298e28501c34c548693e"},{"sha":"ac5a8ffc308eabd67253a9ffa8ff174e628d34f8","author":{"name":"Matthias Schiffer","email":"e0fc9444507b5e43a86498c2a43a0d7ed39b4462@universe-factory.net"},"message":"MIPS: ath79: make bootconsole wait for both THRE and TEMT\n\ncommit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream.\n\nThis makes the ath79 bootconsole behave the same way as the generic 8250\nbootconsole.\n\nAlso waiting for TEMT (transmit buffer is empty) instead of just THRE\n(transmit buffer is not full) ensures that all characters have been\ntransmitted before the real serial driver starts reconfiguring the serial\ncontroller (which would sometimes result in garbage being transmitted.)\nThis change does not cause a visible performance loss.\n\nIn addition, this seems to fix a hang observed in certain configurations on\nmany AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.\n\nA more complete follow-up patch will disable 8250 autoconfig for ath79\naltogether (the serial controller is detected as a 16550A, which is not\nfully compatible with the ath79 serial, and the autoconfig may lead to\nundefined behavior on ath79.)\n\nSigned-off-by: Matthias Schiffer <mschiffer@universe-factory.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/ac5a8ffc308eabd67253a9ffa8ff174e628d34f8"},{"sha":"79925b261448de46f9b4a63fd7bc957953dda170","author":{"name":"Ricky Liang","email":"1286f27e8dad5d3f23572a3ea7d67c2bd47300b3@chromium.org"},"message":"Input: uinput - handle compat ioctl for UI_SET_PHYS\n\ncommit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.\n\nWhen running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS\nioctl needs to be treated with special care, as it has the pointer\nsize encoded in the command.\n\nSigned-off-by: Ricky Liang <jcliang@chromium.org>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/79925b261448de46f9b4a63fd7bc957953dda170"},{"sha":"a887008fdc3a094cce6f2f229ccbd6d83dbdc788","author":{"name":"Joseph Salisbury","email":"26869278fc9b2785c72434a8d890277b71162e51@canonical.com"},"message":"ath5k: Change led pin configuration for compaq c700 laptop\n\ncommit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.\n\nBugLink: http://bugs.launchpad.net/bugs/972604\n\nCommit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d (\"ath5k: add led pin\nconfiguration for compaq c700 laptop\") added a pin configuration for the Compaq\nc700 laptop.  However, the polarity of the led pin is reversed.  It should be\nred for wifi off and blue for wifi on, but it is the opposite.  This bug was\nreported in the following bug report:\nhttp://pad.lv/972604\n\nFixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d (\"ath5k: add led pin configuration for compaq c700 laptop\")\nSigned-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>\nSigned-off-by: Kalle Valo <kvalo@qca.qualcomm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/a887008fdc3a094cce6f2f229ccbd6d83dbdc788"},{"sha":"4b7bac82604956ecda33c48bdbfb33ca37b7f632","author":{"name":"Raghava Aditya Renukunta","email":"1e76b030d44c07b56522e743fd02594085e2d32b@microsemi.com"},"message":"aacraid: Relinquish CPU during timeout wait\n\ncommit 07beca2be24cc710461c0b131832524c9ee08910 upstream.\n\naac_fib_send has a special function case for initial commands during\ndriver initialization using wait < 0(pseudo sync mode). In this case,\nthe command does not sleep but rather spins checking for timeout.This\nloop is calls cpu_relax() in an attempt to allow other processes/threads\nto use the CPU, but this function does not relinquish the CPU and so the\ncommand will hog the processor. This was observed in a KDUMP\n\"crashkernel\" and that prevented the \"command thread\" (which is\nresponsible for completing the command from being timed out) from\nstarting because it could not get the CPU.\n\nFixed by replacing \"cpu_relax()\" call with \"schedule()\"\nSigned-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>\nReviewed-by: Johannes Thumshirn <jthumshirn@suse.de>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/4b7bac82604956ecda33c48bdbfb33ca37b7f632"},{"sha":"70d7df0f978736017d85d8fad91c56231d816249","author":{"name":"Raghava Aditya Renukunta","email":"1e76b030d44c07b56522e743fd02594085e2d32b@microsemi.com"},"message":"aacraid: Fix for aac_command_thread hang\n\ncommit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 upstream.\n\nTypically under error conditions, it is possible for aac_command_thread()\nto miss the wakeup from kthread_stop() and go back to sleep, causing it\nto hang aac_shutdown.\n\nIn the observed scenario, the adapter is not functioning correctly and so\naac_fib_send() never completes (or time-outs depending on how it was\ncalled). Shortly after aac_command_thread() starts it performs\naac_fib_send(SendHostTime) which hangs. When aac_probe_one\n/aac_get_adapter_info send time outs, kthread_stop is called which breaks\nthe command thread out of it's hang.\n\nThe code will still go back to sleep in schedule_timeout() without\nchecking kthread_should_stop() so it causes aac_probe_one to hang until\nthe schedule_timeout() which is 30 minutes.\n\nFixed by: Adding another kthread_should_stop() before schedule_timeout()\nSigned-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>\nReviewed-by: Johannes Thumshirn <jthumshirn@suse.de>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/70d7df0f978736017d85d8fad91c56231d816249"},{"sha":"d1218a64574151420baf6c9e2644e705282df213","author":{"name":"Dave Gerlach","email":"3e06ef4d4921cad6e94c6d4858a41ad0a7a20d1e@ti.com"},"message":"cpuidle: Indicate when a device has been unregistered\n\ncommit c998c07836f985b24361629dc98506ec7893e7a0 upstream.\n\nCurrently the 'registered' member of the cpuidle_device struct is set\nto 1 during cpuidle_register_device. In this same function there are\nchecks to see if the device is already registered to prevent duplicate\ncalls to register the device, but this value is never set to 0 even on\nunregister of the device. Because of this, any attempt to call\ncpuidle_register_device after a call to cpuidle_unregister_device will\nfail which shouldn't be the case.\n\nTo prevent this, set registered to 0 when the device is unregistered.\n\nFixes: c878a52d3c7c (cpuidle: Check if device is already registered)\nSigned-off-by: Dave Gerlach <d-gerlach@ti.com>\nAcked-by: Daniel Lezcano <daniel.lezcano@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/d1218a64574151420baf6c9e2644e705282df213"},{"sha":"4f741c8806969f6343f945f6c12cf06aee25f5a4","author":{"name":"Prarit Bhargava","email":"57afa0c35fd38a11b51d30edc3a65ab805a2449c@redhat.com"},"message":"PCI: Disable all BAR sizing for devices with non-compliant BARs\n\ncommit ad67b437f187ea818b2860524d10f878fadfdd99 upstream.\n\nb84106b4e229 (\"PCI: Disable IO/MEM decoding for devices with non-compliant\nBARs\") disabled BAR sizing for BARs 0-5 of devices that don't comply with\nthe PCI spec.  But it didn't do anything for expansion ROM BARs, so we\nstill try to size them, resulting in warnings like this on Broadwell-EP:\n\n  pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]\n\nMove the non-compliant BAR check from __pci_read_base() up to\npci_read_bases() so it applies to the expansion ROM BAR as well as\nto BARs 0-5.\n\nNote that direct callers of __pci_read_base(), like sriov_init(), will now\nbypass this check.  We haven't had reports of devices with broken SR-IOV\nBARs yet.\n\n[bhelgaas: changelog]\nFixes: b84106b4e229 (\"PCI: Disable IO/MEM decoding for devices with non-compliant BARs\")\nSigned-off-by: Prarit Bhargava <prarit@redhat.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nCC: Thomas Gleixner <tglx@linutronix.de>\nCC: Ingo Molnar <mingo@redhat.com>\nCC: \"H. Peter Anvin\" <hpa@zytor.com>\nCC: Andi Kleen <ak@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/4f741c8806969f6343f945f6c12cf06aee25f5a4"},{"sha":"b459bc762398544e7d27cd543b5e72850f1e65c1","author":{"name":"wang yanqing","email":"bcfcdb54ab7ba3dbbd331cdc9900bdd15aafced3@gmail.com"},"message":"rtlwifi: Fix logic error in enter/exit power-save mode\n\ncommit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.\n\nIn commit a269913c52ad (\"rtlwifi: Rework rtl_lps_leave() and\nrtl_lps_enter() to use work queue\"), the tests for enter/exit\npower-save mode were inverted. With this change applied, the\nwifi connection becomes much more stable.\n\nFixes: a269913c52ad (\"rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue\")\nSigned-off-by: Wang YanQing <udknight@gmail.com>\nAcked-by: Larry Finger <Larry.Finger@lwfinger.net>\nSigned-off-by: Kalle Valo <kvalo@codeaurora.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/b459bc762398544e7d27cd543b5e72850f1e65c1"},{"sha":"a952b0abde1c4502fd98fdba74859cb4ca6f4f78","author":{"name":"Ben Hutchings","email":"9c85637c38b80821c7bd8a03bde7b59da81ab77d@decadent.org.uk"},"message":"pipe: Fix buffer offset after partially failed read\n\ncommit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2 upstream.\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\nReferences: https://rhn.redhat.com/errata/RHSA-2016-0103.html\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nCc: Willy Tarreau <w@1wt.eu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/a952b0abde1c4502fd98fdba74859cb4ca6f4f78"},{"sha":"646e7ae79a3dafa5b8b117a0d04405951634ad41","author":{"name":"Hari Bathini","email":"2a6f2d104e06e8f2dcfd14fdac1884bda5bb5604@linux.vnet.ibm.com"},"message":"powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel\n\ncommit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream.\n\nSome of the interrupt vectors on 64-bit POWER server processors are only\n32 bytes long (8 instructions), which is not enough for the full\nfirst-level interrupt handler. For these we need to branch to an\nout-of-line (OOL) handler. But when we are running a relocatable kernel,\ninterrupt vectors till __end_interrupts marker are copied down to real\naddress 0x100. So, branching to labels (ie. OOL handlers) outside this\nsection must be handled differently (see LOAD_HANDLER()), considering\nrelocatable kernel, which would need at least 4 instructions.\n\nHowever, branching from interrupt vector means that we corrupt the\nCFAR (come-from address register) on POWER7 and later processors as\nmentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)\nthat contains the part up to the point where the CFAR is saved in the\nPACA should be part of the short interrupt vectors before we branch out\nto OOL handlers.\n\nBut as mentioned already, there are interrupt vectors on 64-bit POWER\nserver processors that are only 32 bytes long (like vectors 0x4f00,\n0x4f20, etc.), which cannot accomodate the above two cases at the same\ntime owing to space constraint. Currently, in these interrupt vectors,\nwe simply branch out to OOL handlers, without using LOAD_HANDLER(),\nwhich leaves us vulnerable when running a relocatable kernel (eg. kdump\ncase). While this has been the case for sometime now and kdump is used\nwidely, we were fortunate not to see any problems so far, for three\nreasons:\n\n  1. In almost all cases, production kernel (relocatable) is used for\n     kdump as well, which would mean that crashed kernel's OOL handler\n     would be at the same place where we end up branching to, from short\n     interrupt vector of kdump kernel.\n  2. Also, OOL handler was unlikely the reason for crash in almost all\n     the kdump scenarios, which meant we had a sane OOL handler from\n     crashed kernel that we branched to.\n  3. On most 64-bit POWER server processors, page size is large enough\n     that marking interrupt vector code as executable (see commit\n     429d2e83) leads to marking OOL handler code from crashed kernel,\n     that sits right below interrupt vector code from kdump kernel, as\n     executable as well.\n\nLet us fix this by moving the __end_interrupts marker down past OOL\nhandlers to make sure that we also copy OOL handlers to real address\n0x100 when running a relocatable kernel.\n\nThis fix has been tested successfully in kdump scenario, on an LPAR with\n4K page size by using different default/production kernel and kdump\nkernel.\n\nAlso tested by manually corrupting the OOL handlers in the first kernel\nand then kdump'ing, and then causing the OOL handlers to fire - mpe.\n\nFixes: c1fb6816fb1b (\"powerpc: Add relocation on exception vector handlers\")\nSigned-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/646e7ae79a3dafa5b8b117a0d04405951634ad41"},{"sha":"aa77dea436de2eb3be817b96e573ca3ef856d7c3","author":{"name":"Ross Lagerwall","email":"f90a2f76f02e7b33a9ce8743551479ba4fbf9040@citrix.com"},"message":"xen/events: Don't move disabled irqs\n\ncommit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.\n\nCommit ff1e22e7a638 (\"xen/events: Mask a moving irq\") open-coded\nirq_move_irq() but left out checking if the IRQ is disabled. This broke\nresuming from suspend since it tries to move a (disabled) irq without\nholding the IRQ's desc->lock. Fix it by adding in a check for disabled\nIRQs.\n\nThe resulting stacktrace was:\nkernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!\ninvalid opcode: 0000 [#1] SMP\nModules linked in: xenfs xen_privcmd ...\nCPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu\nHardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016\ntask: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000\nRIP: 0010:[<ffffffff810e26e2>]  [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0\nRSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046\nRAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001\nRDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8\nRBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000\nR10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0\nR13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff\nFS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nStack:\n ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0\n ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009\n 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66\nCall Trace:\n [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0\n [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150\n [<ffffffff814ca659>] xen_irq_resume+0x319/0x360\n [<ffffffff814c7e75>] xen_suspend+0xb5/0x180\n [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0\n [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80\n [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140\n [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220\n [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20\n [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160\n [<ffffffff810a3830>] ? sort_range+0x30/0x30\n [<ffffffff810a0588>] kthread+0xd8/0xf0\n [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0\n [<ffffffff8182568f>] ret_from_fork+0x3f/0x70\n [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0\n\nSigned-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>\nReviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nSigned-off-by: David Vrabel <david.vrabel@citrix.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/aa77dea436de2eb3be817b96e573ca3ef856d7c3"},{"sha":"89bd18288361ac9f737e1b805c6524fa513a50e9","author":{"name":"Tomáš Trnka","email":"5c095c62499f2343793bd77d56fffa239d30efc3@mail.muni.cz"},"message":"sunrpc: fix stripping of padded MIC tokens\n\ncommit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream.\n\nThe length of the GSS MIC token need not be a multiple of four bytes.\nIt is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()\nwould previously only trim mic.len + 4 B. The remaining up to three\nbytes would then trigger a check in nfs4svc_decode_compoundargs(),\nleading to a \"garbage args\" error and mount failure:\n\nnfs4svc_decode_compoundargs: compound not properly padded!\nnfsd: failed to decode arguments!\n\nThis would prevent older clients using the pre-RFC 4121 MIC format\n(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+\nservers using krb5i.\n\nThe trimming was introduced by commit 4c190e2f913f (\"sunrpc: trim off\ntrailing checksum before returning decrypted or integrity authenticated\nbuffer\").\n\nFixes: 4c190e2f913f \"unrpc: trim off trailing checksum...\"\nSigned-off-by: Tomáš Trnka <ttrnka@mail.muni.cz>\nAcked-by: Jeff Layton <jlayton@poochiereds.net>\nSigned-off-by: J. Bruce Fields <bfields@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/89bd18288361ac9f737e1b805c6524fa513a50e9"},{"sha":"369168dfae6fded212a7c43c9df8e58b604d9160","author":{"name":"Itai Handler","email":"9a75d315a710024297a8ea012420e518c15094e0@hotmail.com"},"message":"drm/gma500: Fix possible out of bounds read\n\ncommit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.\n\nFix possible out of bounds read, by adding missing comma.\nThe code may read pass the end of the dsi_errors array\nwhen the most significant bit (bit #31) in the intr_stat register\nis set.\nThis bug has been detected using CppCheck (static analysis tool).\n\nSigned-off-by: Itai Handler <itai_handler@hotmail.com>\nSigned-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/369168dfae6fded212a7c43c9df8e58b604d9160"},{"sha":"4bb87c0487e7b7c009d195310f8aeda63d61e2c5","author":{"name":"Lyude","email":"1f81f7ac2b1fc68743525d150f68a4801a32c99d@redhat.com"},"message":"drm/fb_helper: Fix references to dev->mode_config.num_connector\n\ncommit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.\n\nDuring boot, MST hotplugs are generally expected (even if no physical\nhotplugging occurs) and result in DRM's connector topology changing.\nThis means that using num_connector from the current mode configuration\ncan lead to the number of connectors changing under us. This can lead to\nsome nasty scenarios in fbcon:\n\n- We allocate an array to the size of dev->mode_config.num_connectors.\n- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.\n- We try to loop through each element in the array using the new value\n  of dev->mode_config.num_connectors, and end up going out of bounds\n  since dev->mode_config.num_connectors is now larger then the array we\n  allocated.\n\nfb_helper->connector_count however, will always remain consistent while\nwe do a modeset in fb_helper.\n\nNote: This is just polish for 4.7, Dave Airlie's drm_connector\nrefcounting fixed these bugs for real. But it's good enough duct-tape\nfor stable kernel backporting, since backporting the refcounting\nchanges is way too invasive.\n\nSigned-off-by: Lyude <cpaul@redhat.com>\n[danvet: Clarify why we need this. Also remove the now unused \"dev\"\nlocal variable to appease gcc.]\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nLink: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/4bb87c0487e7b7c009d195310f8aeda63d61e2c5"},{"sha":"d537a94dbb33f5b14386c933b7f9d52e445f0462","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"ext4: fix hang when processing corrupted orphaned inode list\n\ncommit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream.\n\nIf the orphaned inode list contains inode #5, ext4_iget() returns a\nbad inode (since the bootloader inode should never be referenced\ndirectly).  Because of the bad inode, we end up processing the inode\nrepeatedly and this hangs the machine.\n\nThis can be reproduced via:\n\n   mke2fs -t ext4 /tmp/foo.img 100\n   debugfs -w -R \"ssv last_orphan 5\" /tmp/foo.img\n   mount -o loop /tmp/foo.img /mnt\n\n(But don't do this if you are using an unpatched kernel if you care\nabout the system staying functional.  :-)\n\nThis bug was found by the port of American Fuzzy Lop into the kernel\nto find file system problems[1].  (Since it *only* happens if inode #5\nshows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not\nsurprising that AFL needed two hours before it found it.)\n\n[1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf\n\nReported by: Vegard Nossum <vegard.nossum@oracle.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/d537a94dbb33f5b14386c933b7f9d52e445f0462"},{"sha":"7e8f21840bda9fc19db14ee92fd118a0c533eb5a","author":{"name":"Nicolai Stange","email":"32f39f7586f1ea41688e98d8c88016b9ed0d780b@gmail.com"},"message":"ext4: address UBSAN warning in mb_find_order_for_block()\n\ncommit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream.\n\nCurrently, in mb_find_order_for_block(), there's a loop like the following:\n\n  while (order <= e4b->bd_blkbits + 1) {\n    ...\n    bb += 1 << (e4b->bd_blkbits - order);\n  }\n\nNote that the updated bb is used in the loop's next iteration only.\n\nHowever, at the last iteration, that is at order == e4b->bd_blkbits + 1,\nthe shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports\n\n  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11\n  shift exponent -1 is negative\n  [...]\n  Call Trace:\n   [<ffffffff818c4d35>] dump_stack+0xbc/0x117\n   [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169\n   [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e\n   [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254\n   [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158\n   [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590\n   [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80\n   [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240\n   [...]\n\nUnless compilers start to do some fancy transformations (which at least\nGCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the\nsuch calculated value of bb is never used again.\n\nSilence UBSAN by introducing another variable, bb_incr, holding the next\nincrement to apply to bb and adjust that one by right shifting it by one\nposition per loop iteration.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161\n\nSigned-off-by: Nicolai Stange <nicstange@gmail.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/7e8f21840bda9fc19db14ee92fd118a0c533eb5a"},{"sha":"6871905c9ab0604469f35b36a0aa13e117deb0f0","author":{"name":"Nicolai Stange","email":"32f39f7586f1ea41688e98d8c88016b9ed0d780b@gmail.com"},"message":"ext4: silence UBSAN in ext4_mb_init()\n\ncommit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.\n\nCurrently, in ext4_mb_init(), there's a loop like the following:\n\n  do {\n    ...\n    offset += 1 << (sb->s_blocksize_bits - i);\n    i++;\n  } while (i <= sb->s_blocksize_bits + 1);\n\nNote that the updated offset is used in the loop's next iteration only.\n\nHowever, at the last iteration, that is at i == sb->s_blocksize_bits + 1,\nthe shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))\nand UBSAN reports\n\n  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15\n  shift exponent 4294967295 is too large for 32-bit type 'int'\n  [...]\n  Call Trace:\n   [<ffffffff818c4d25>] dump_stack+0xbc/0x117\n   [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169\n   [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e\n   [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254\n   [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158\n   [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390\n   [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0\n   [<ffffffff814293c7>] ? create_cache+0x57/0x1f0\n   [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0\n   [<ffffffff821c2168>] ? mutex_lock+0x38/0x60\n   [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50\n   [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0\n   [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0\n   [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0\n   [...]\n\nObserve that the mentioned shift exponent, 4294967295, equals (unsigned)-1.\n\nUnless compilers start to do some fancy transformations (which at least\nGCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the\nsuch calculated value of offset is never used again.\n\nSilence UBSAN by introducing another variable, offset_incr, holding the\nnext increment to apply to offset and adjust that one by right shifting it\nby one position per loop iteration.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161\n\nSigned-off-by: Nicolai Stange <nicstange@gmail.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/6871905c9ab0604469f35b36a0aa13e117deb0f0"},{"sha":"07a9b7bd6bbfff80423ac6c77c35ae922d2559fc","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"dma-debug: avoid spinlock recursion when disabling dma-debug\n\ncommit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream.\n\nWith netconsole (at least) the pr_err(\"...  disablingn\") call can\nrecurse back into the dma-debug code, where it'll try to grab\nfree_entries_lock again.  Avoid the problem by doing the printk after\ndropping the lock.\n\nLink: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\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/Jackeagle/kernel_msm/commits/07a9b7bd6bbfff80423ac6c77c35ae922d2559fc"}]}
{"actor":{"display_login":"Jackeagle"}}