{"push_id":1076206712,"size":298,"distinct_size":1,"ref":"refs/heads/tuxonice-3.10","head":"50d7d9fbe903f97f3d519e8a70990e9c824dd155","before":"7b33676aaadb52c421c09995498362b97c3e95dd","commits":[{"sha":"85ec9232455406f1453bff56d8ef83c2aa2281c3","author":{"email":"aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","name":"Willy Tarreau"},"message":"af_unix: fix incorrect revert of 'lock_interruptible' in stream receive code\n\nAs reported by Sultan Qasim, commit 3822b5c (\"af_unix: Revert\n'lock_interruptible' in stream receive code\") was accidently applied\nat the wrong place in the backport that appeared in 3.10.95, it\naffected unix_dgram_recvmsg() instead of unix_stream_recvmsg() due\nto now similar code sections there. The dgram part needs to remain\nbut the stream part needs to be removed.\n\nReported-By: Sultan Qasim <sultanqasim@gmail.com>\nFixes: 3a57e78 (3.10.95)\nSigned-off-by: Willy Tarreau <w@1wt.eu>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/85ec9232455406f1453bff56d8ef83c2aa2281c3"},{"sha":"c511958e1c0b0a802ba68a7bf689b33ee8877f6b","author":{"email":"bca05f431daa7b310c1bddb44dde45fd267309e3@altlinux.org","name":"Dmitry V. Levin"},"message":"x86/signal: Fix restart_syscall number for x32 tasks\n\ncommit 22eab1108781eff09961ae7001704f7bd8fb1dce upstream.\n\nWhen restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,\nregs->ax is assigned to a restart_syscall number.  For x32 tasks, this\nsyscall number must have __X32_SYSCALL_BIT set, otherwise it will be\nan x86_64 syscall number instead of a valid x32 syscall number. This\nissue has been there since the introduction of x32.\n\nReported-by: strace/tests/restart_syscall.test\nReported-and-tested-by: Elvira Khabirova <lineprinter0@gmail.com>\nSigned-off-by: Dmitry V. Levin <ldv@altlinux.org>\nCc: Elvira Khabirova <lineprinter0@gmail.com>\nLink: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/c511958e1c0b0a802ba68a7bf689b33ee8877f6b"},{"sha":"723e01b02a017a2c2889202487a20c778f1f0bd6","author":{"email":"b41c17b861974b03cec38e3ec2992769b9bfae55@oracle.com","name":"Boris Ostrovsky"},"message":"xen/gntdev: Grant maps should not be subject to NUMA balancing\n\ncommit 9c17d96500f78d7ecdb71ca6942830158bc75a2b upstream.\n\nDoing so will cause the grant to be unmapped and then, during\nfault handling, the fault to be mistakenly treated as NUMA hint\nfault.\n\nIn addition, even if those maps could partcipate in NUMA\nbalancing, it wouldn't provide any benefit since we are unable\nto determine physical page's node (even if/when VNUMA is\nimplemented).\n\nMarking grant maps' VMAs as VM_IO will exclude them from being\npart of NUMA balancing.\n\nSigned-off-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":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/723e01b02a017a2c2889202487a20c778f1f0bd6"},{"sha":"c55958f9a88de41d7e145e146fea4d4fcf0a4be2","author":{"email":"1f90cf9f066a1ff68e9fdbb4cca9ba9a8f64650f@huawei.com","name":"Ouyang Zhaowei (Charles)"},"message":"x86/xen: don't reset vcpu_info on a cancelled suspend\n\ncommit 6a1f513776b78c994045287073e55bae44ed9f8c upstream.\n\nOn a cancelled suspend the vcpu_info location does not change (it's\nstill in the per-cpu area registered by xen_vcpu_setup()).  So do not\ncall xen_hvm_init_shared_info() which would make the kernel think its\nback in the shared info.  With the wrong vcpu_info, events cannot be\nreceived and the domain will hang after a cancelled suspend.\n\nSigned-off-by: Charles Ouyang <ouyangzhaowei@huawei.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":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/c55958f9a88de41d7e145e146fea4d4fcf0a4be2"},{"sha":"d59f772b7147650484bb8922c28ca0e4c9407a31","author":{"email":"19a0ba370c443ba08d20b5061586430ab449ee8c@ozlabs.org","name":"Paul Mackerras"},"message":"KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR\n\ncommit c20875a3e638e4a03e099b343ec798edd1af5cc6 upstream.\n\nCurrently it is possible for userspace (e.g. QEMU) to set a value\nfor the MSR for a guest VCPU which has both of the TS bits set,\nwhich is an illegal combination.  The result of this is that when\nwe execute a hrfid (hypervisor return from interrupt doubleword)\ninstruction to enter the guest, the CPU will take a TM Bad Thing\ntype of program interrupt (vector 0x700).\n\nNow, if PR KVM is configured in the kernel along with HV KVM, we\nactually handle this without crashing the host or giving hypervisor\nprivilege to the guest; instead what happens is that we deliver a\nprogram interrupt to the guest, with SRR0 reflecting the address\nof the hrfid instruction and SRR1 containing the MSR value at that\npoint.  If PR KVM is not configured in the kernel, then we try to\nrun the host's program interrupt handler with the MMU set to the\nguest context, which almost certainly causes a host crash.\n\nThis closes the hole by making kvmppc_set_msr_hv() check for the\nillegal combination and force the TS field to a safe value (00,\nmeaning non-transactional).\n\nSigned-off-by: Paul Mackerras <paulus@samba.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/d59f772b7147650484bb8922c28ca0e4c9407a31"},{"sha":"a919f20b062eb4cfc65bb14b7cacf898747f803c","author":{"email":"1e0b3b0517a6c13598ed894fc921c5c62f243c44@gmail.com","name":"Mario Kleiner"},"message":"x86/reboot/quirks: Add iMac10,1 to pci_reboot_dmi_table[]\n\ncommit 2f0c0b2d96b1205efb14347009748d786c2d9ba5 upstream.\n\nWithout the reboot=pci method, the iMac 10,1 simply\nhangs after printing \"Restarting system\" at the point\nwhen it should reboot. This fixes it.\n\nSigned-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Brian Gerst <brgerst@gmail.com>\nCc: Dave Jones <davej@codemonkey.org.uk>\nCc: Denys Vlasenko <dvlasenk@redhat.com>\nCc: H. Peter Anvin <hpa@zytor.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nLink: http://lkml.kernel.org/r/1450466646-26663-1-git-send-email-mario.kleiner.de@gmail.com\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/NigelCunningham/tuxonice-kernel/commits/a919f20b062eb4cfc65bb14b7cacf898747f803c"},{"sha":"6ec8f1c4d643ca779ef51cf4c74440b4b08658d2","author":{"email":"e6b730070cb8ff71eb70dcaf29e26324d883b33b@gmail.com","name":"H.J. Lu"},"message":"x86/boot: Double BOOT_HEAP_SIZE to 64KB\n\ncommit 8c31902cffc4d716450be549c66a67a8a3dd479c upstream.\n\nWhen decompressing kernel image during x86 bootup, malloc memory\nfor ELF program headers may run out of heap space, which leads\nto system halt.  This patch doubles BOOT_HEAP_SIZE to 64KB.\n\nTested with 32-bit kernel which failed to boot without this patch.\n\nSigned-off-by: H.J. Lu <hjl.tools@gmail.com>\nAcked-by: H. Peter Anvin <hpa@zytor.com>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Brian Gerst <brgerst@gmail.com>\nCc: Denys Vlasenko <dvlasenk@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-kernel@vger.kernel.org\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/NigelCunningham/tuxonice-kernel/commits/6ec8f1c4d643ca779ef51cf4c74440b4b08658d2"},{"sha":"dd66c0e1dfefeffcf7278d225aed0996745125e4","author":{"email":"1cdc26788c5bb66f1c315a7f9f8b93926cbf61a9@redhat.com","name":"Jan Stancek"},"message":"ipmi: move timer init to before irq is setup\n\ncommit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.\n\nWe encountered a panic on boot in ipmi_si on a dell per320 due to an\nuninitialized timer as follows.\n\nstatic int smi_start_processing(void       *send_info,\n                                ipmi_smi_t intf)\n{\n        /* Try to claim any interrupts. */\n        if (new_smi->irq_setup)\n                new_smi->irq_setup(new_smi);\n\n --> IRQ arrives here and irq handler tries to modify uninitialized timer\n\n    which triggers BUG_ON(!timer->function) in __mod_timer().\n\n Call Trace:\n   <IRQ>\n   [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]\n   [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]\n   [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]\n   [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350\n   [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]\n   [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170\n   [<ffffffff810f245e>] handle_edge_irq+0xde/0x180\n   [<ffffffff8100fc59>] handle_irq+0x49/0xa0\n   [<ffffffff8154643c>] do_IRQ+0x6c/0xf0\n   [<ffffffff8100ba53>] ret_from_intr+0x0/0x11\n\n        /* Set up the timer that drives the interface. */\n        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);\n\nThe following patch fixes the problem.\n\nTo: Openipmi-developer@lists.sourceforge.net\nTo: Corey Minyard <minyard@acm.org>\nCC: linux-kernel@vger.kernel.org\n\nSigned-off-by: Jan Stancek <jstancek@redhat.com>\nSigned-off-by: Tony Camuso <tcamuso@redhat.com>\nSigned-off-by: Corey Minyard <cminyard@mvista.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/dd66c0e1dfefeffcf7278d225aed0996745125e4"},{"sha":"6e14ea99a6635d13798755516ae6bd1061d177cb","author":{"email":"da19f0d1311a690ef93489efaf9b0ff7bd44ca5d@linux.intel.com","name":"Alexandra Yates"},"message":"ALSA: hda - Add Intel Lewisburg device IDs Audio\n\ncommit 5cf92c8b3dc5da59e05dc81bdc069cedf6f38313 upstream.\n\nAdding Intel codename Lewisburg platform device IDs for audio.\n\n[rearranged the position by tiwai]\n\nSigned-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/6e14ea99a6635d13798755516ae6bd1061d177cb"},{"sha":"b768cd78b5cc44f8175aaf443b0c68c7957ff548","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: hda - Apply pin fixup for HP ProBook 6550b\n\ncommit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.\n\nHP ProBook 6550b needs the same pin fixup applied to other HP B-series\nlaptops with docks for making its headphone and dock headphone jacks\nworking properly.  We just need to add the codec SSID to the list.\n\nBugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/b768cd78b5cc44f8175aaf443b0c68c7957ff548"},{"sha":"43702b71b470a629db5729048ecb1b2bed64fd36","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: rme96: Fix unexpected volume reset after rate changes\n\ncommit a74a821624c0c75388a193337babd17a8c02c740 upstream.\n\nrme96 driver needs to reset DAC depending on the sample rate, and this\nresults in resetting to the max volume suddenly.  It's because of the\nmissing call of snd_rme96_apply_dac_volume().\n\nHowever, calling this function right after the DAC reset still may not\nwork, and we need some delay before this call.  Since the DAC reset\nand the procedure after that are performed in the spinlock, we delay\nthe DAC volume restore at the end after the spinlock.\n\nReported-and-tested-by: Sylvain LABOISNE <maeda1@free.fr>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/43702b71b470a629db5729048ecb1b2bed64fd36"},{"sha":"ae8ca6a01960835451ee12002a30da4c23ec90ca","author":{"email":"9fb354e0a5603a0331399c18f4aa5aab2f9d9c5b@canonical.com","name":"David Henningsson"},"message":"ALSA: hda - Add inverted dmic for Packard Bell DOTS\n\ncommit 02f6ff90400d055f08b0ba0b5f0707630b6faed7 upstream.\n\nOn the internal mic of the Packard Bell DOTS, one channel\nhas an inverted signal. Add a quirk to fix this up.\n\nBugLink: https://bugs.launchpad.net/bugs/1523232\nSigned-off-by: David Henningsson <david.henningsson@canonical.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/ae8ca6a01960835451ee12002a30da4c23ec90ca"},{"sha":"4b98be841c36660c6d624e1cb8d78b36c08123db","author":{"email":"887154684953c1d7bc9f653d05b20c8de98c15bc@intel.com","name":"Xiong Zhang"},"message":"ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()\n\ncommit 3e6db33aaf1d42a30339f831ec4850570d6cc7a3 upstream.\n\nIt takes three minutes to enter into hibernation on some OEM SKL\nmachines and we see many codec spurious response after thaw() opertion.\nThis is because HDA is still in D0 state after freeze() call and\npci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.\nIt seems bios still access HDA when system enter into freeze state,\nHDA will receive codec response interrupt immediately after thaw() call.\nBecause of this unexpected interrupt, HDA enter into a abnormal\nstate and slow down the system enter into hibernation.\n\nIn this patch, we put HDA into D3 hot state in azx_freeze_noirq() and\nput HDA into D0 state in azx_thaw_noirq().\n\nV2: Only apply this fix to SKL+\n    Fix compile error when CONFIG_PM_SLEEP isn't defined\n\n[Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment\n by tiwai]\n\nSigned-off-by: Xiong Zhang <xiong.y.zhang@intel.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/4b98be841c36660c6d624e1cb8d78b36c08123db"},{"sha":"9cb16b5349c47c2ce33d34d57da14a8f071175bf","author":{"email":"1e0b3b0517a6c13598ed894fc921c5c62f243c44@gmail.com","name":"Mario Kleiner"},"message":"ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)\n\ncommit 9f660a1c43890c2cdd1f423fd73654e7ca08fe56 upstream.\n\nWithout this patch, internal speaker and line-out work,\nbut front headphone output jack stays silent on the\nMac Pro 4,1.\n\nThis code path also gets executed on the MacPro 5,1 due\nto identical codec SSID, but i don't know if it has any\npositive or adverse effects there or not.\n\n(v2) Implement feedback from Takashi Iwai: Reuse\n     alc889_fixup_mbp_vref and just add a new nid\n     0x19 for the MacPro 4,1.\n\nSigned-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/9cb16b5349c47c2ce33d34d57da14a8f071175bf"},{"sha":"b85a6198e28f573d6df99522782aa09948258d19","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: seq: Fix missing NULL check at remove_events ioctl\n\ncommit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream.\n\nsnd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()\nunconditionally even if there is no FIFO assigned, and this leads to\nan Oops due to NULL dereference.  The fix is just to add a proper NULL\ncheck.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/b85a6198e28f573d6df99522782aa09948258d19"},{"sha":"6e29b1cc3071f1c41a943e8e873f34e454428bda","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: seq: Fix race at timer setup and close\n\ncommit 3567eb6af614dac436c4b16a8d426f9faed639b3 upstream.\n\nALSA sequencer code has an open race between the timer setup ioctl and\nthe close of the client.  This was triggered by syzkaller fuzzer, and\na use-after-free was caught there as a result.\n\nThis patch papers over it by adding a proper queue->timer_mutex lock\naround the timer-related calls in the relevant code path.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/6e29b1cc3071f1c41a943e8e873f34e454428bda"},{"sha":"ea83c96e843d4e48db874e58ec6a261d94ce7077","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: timer: Harden slave timer list handling\n\ncommit b5a663aa426f4884c71cd8580adae73f33570f0d upstream.\n\nA slave timer instance might be still accessible in a racy way while\noperating the master instance as it lacks of locking.  Since the\nmaster operation is mostly protected with timer->lock, we should cope\nwith it while changing the slave instance, too.  Also, some linked\nlists (active_list and ack_list) of slave instances aren't unlinked\nimmediately at stopping or closing, and this may lead to unexpected\naccesses.\n\nThis patch tries to address these issues.  It adds spin lock of\ntimer->lock (either from master or slave, which is equivalent) in a\nfew places.  For avoiding a deadlock, we ensure that the global\nslave_active_lock is always locked at first before each timer lock.\n\nAlso, ack and active_list of slave instances are properly unlinked at\nsnd_timer_stop() and snd_timer_close().\n\nLast but not least, remove the superfluous call of _snd_timer_stop()\nat removing slave links.  This is a noop, and calling it may confuse\nreaders wrt locking.  Further cleanup will follow in a later patch.\n\nActually we've got reports of use-after-free by syzkaller fuzzer, and\nthis hopefully fixes these issues.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/ea83c96e843d4e48db874e58ec6a261d94ce7077"},{"sha":"a49bdee155fde66928197108cece545d49edec17","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: timer: Fix race among timer ioctls\n\ncommit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream.\n\nALSA timer ioctls have an open race and this may lead to a\nuse-after-free of timer instance object.  A simplistic fix is to make\neach ioctl exclusive.  We have already tread_sem for controlling the\ntread, and extend this as a global mutex to be applied to each ioctl.\n\nThe downside is, of course, the worse concurrency.  But these ioctls\naren't to be parallel accessible, in anyway, so it should be fine to\nserialize there.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/a49bdee155fde66928197108cece545d49edec17"},{"sha":"fd6788c0ba7aaa46f47f90166759ae32c06c5abd","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: timer: Fix double unlink of active_list\n\ncommit ee8413b01045c74340aa13ad5bdf905de32be736 upstream.\n\nALSA timer instance object has a couple of linked lists and they are\nunlinked unconditionally at snd_timer_stop().  Meanwhile\nsnd_timer_interrupt() unlinks it, but it calls list_del() which leaves\nthe element list itself unchanged.  This ends up with unlinking twice,\nand it was caught by syzkaller fuzzer.\n\nThe fix is to use list_del_init() variant properly there, too.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/fd6788c0ba7aaa46f47f90166759ae32c06c5abd"},{"sha":"870566bafcc9e806816048f9a1d952300e8dcba5","author":{"email":"f3daba1cdc403799935674d3cd4b0e5bd1804232@chromium.org","name":"Nicolas Boichat"},"message":"ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode\n\ncommit 9586495dc3011a80602329094e746dbce16cb1f1 upstream.\n\nThis reverts one hunk of\ncommit ef44a1ec6eee (\"ALSA: sound/core: use memdup_user()\"), which\nreplaced a number of kmalloc followed by memcpy with memdup calls.\n\nIn this case, we are copying from a struct snd_seq_port_info32 to a\nstruct snd_seq_port_info, but the latter is 4 bytes longer than the\n32-bit version, so we need to separate kmalloc and copy calls.\n\nFixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()')\nSigned-off-by: Nicolas Boichat <drinkcat@chromium.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/870566bafcc9e806816048f9a1d952300e8dcba5"}]}