--- /dev/null
+From 493626f2d87a74e6dbea1686499ed6e7e600484e Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Sun, 9 Sep 2018 22:25:12 +0900
+Subject: ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream.
+
+When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST',
+an address of 'payload' argument is used for streaming DMA mapping by
+'firewire_ohci' module if 'size' argument is larger than 8 byte.
+Although in this case the address should not be on kernel stack, current
+implementation of ALSA bebob driver uses data in kernel stack for a cue
+to boot M-Audio devices. This often brings unexpected result, especially
+for a case of CONFIG_VMAP_STACK=y.
+
+This commit fixes the bug.
+
+Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021
+Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165
+Fixes: a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')
+Cc: <stable@vger.kernel.org> # v3.16+
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/firewire/bebob/bebob_maudio.c | 24 ++++++++++++++----------
+ 1 file changed, 14 insertions(+), 10 deletions(-)
+
+--- a/sound/firewire/bebob/bebob_maudio.c
++++ b/sound/firewire/bebob/bebob_maudio.c
+@@ -96,17 +96,13 @@ int snd_bebob_maudio_load_firmware(struc
+ struct fw_device *device = fw_parent_device(unit);
+ int err, rcode;
+ u64 date;
+- __le32 cues[3] = {
+- cpu_to_le32(MAUDIO_BOOTLOADER_CUE1),
+- cpu_to_le32(MAUDIO_BOOTLOADER_CUE2),
+- cpu_to_le32(MAUDIO_BOOTLOADER_CUE3)
+- };
++ __le32 *cues;
+
+ /* check date of software used to build */
+ err = snd_bebob_read_block(unit, INFO_OFFSET_SW_DATE,
+ &date, sizeof(u64));
+ if (err < 0)
+- goto end;
++ return err;
+ /*
+ * firmware version 5058 or later has date later than "20070401", but
+ * 'date' is not null-terminated.
+@@ -114,20 +110,28 @@ int snd_bebob_maudio_load_firmware(struc
+ if (date < 0x3230303730343031LL) {
+ dev_err(&unit->device,
+ "Use firmware version 5058 or later\n");
+- err = -ENOSYS;
+- goto end;
++ return -ENXIO;
+ }
+
++ cues = kmalloc_array(3, sizeof(*cues), GFP_KERNEL);
++ if (!cues)
++ return -ENOMEM;
++
++ cues[0] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE1);
++ cues[1] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE2);
++ cues[2] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE3);
++
+ rcode = fw_run_transaction(device->card, TCODE_WRITE_BLOCK_REQUEST,
+ device->node_id, device->generation,
+ device->max_speed, BEBOB_ADDR_REG_REQ,
+- cues, sizeof(cues));
++ cues, 3 * sizeof(*cues));
++ kfree(cues);
+ if (rcode != RCODE_COMPLETE) {
+ dev_err(&unit->device,
+ "Failed to send a cue to load firmware\n");
+ err = -EIO;
+ }
+-end:
++
+ return err;
+ }
+
--- /dev/null
+From 49434c6c575d2008c0abbc93e615019f39e01252 Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Sat, 8 Sep 2018 08:12:21 +0200
+Subject: ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO
+
+From: Willy Tarreau <w@1wt.eu>
+
+commit 49434c6c575d2008c0abbc93e615019f39e01252 upstream.
+
+snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates
+memory using kmalloc() and partially fills it by calling
+snd_emu10k1_fx8010_info() before returning the resulting
+structure to userspace, leaving uninitialized holes. Let's
+just use kzalloc() here.
+
+BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html
+Signed-off-by: Willy Tarreau <w@1wt.eu>
+Cc: Jann Horn <jannh@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/emu10k1/emufx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/emu10k1/emufx.c
++++ b/sound/pci/emu10k1/emufx.c
+@@ -2521,7 +2521,7 @@ static int snd_emu10k1_fx8010_ioctl(stru
+ emu->support_tlv = 1;
+ return put_user(SNDRV_EMU10K1_VERSION, (int __user *)argp);
+ case SNDRV_EMU10K1_IOCTL_INFO:
+- info = kmalloc(sizeof(*info), GFP_KERNEL);
++ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+ snd_emu10k1_fx8010_info(emu, info);
--- /dev/null
+From 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?=
+ <sebastien.szymanski@armadeus.com>
+Date: Thu, 6 Sep 2018 11:16:00 +0200
+Subject: ASoC: cs4265: fix MMTLR Data switch control
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+
+commit 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 upstream.
+
+The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0
+and not at address 0x0 bit 1. Fix this.
+
+Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/codecs/cs4265.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/codecs/cs4265.c
++++ b/sound/soc/codecs/cs4265.c
+@@ -174,8 +174,8 @@ static const struct snd_kcontrol_new cs4
+ SOC_SINGLE("Validity Bit Control Switch", CS4265_SPDIF_CTL2,
+ 3, 1, 0),
+ SOC_ENUM("SPDIF Mono/Stereo", spdif_mono_stereo_enum),
+- SOC_SINGLE("MMTLR Data Switch", 0,
+- 1, 1, 0),
++ SOC_SINGLE("MMTLR Data Switch", CS4265_SPDIF_CTL2,
++ 0, 1, 0),
+ SOC_ENUM("Mono Channel Select", spdif_mono_select_enum),
+ SND_SOC_BYTES("C Data Buffer", CS4265_C_DATA_BUFF, 24),
+ };
--- /dev/null
+From b45d71fb89ab8adfe727b9d0ee188ed58582a647 Mon Sep 17 00:00:00 2001
+From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
+Date: Thu, 20 Sep 2018 12:22:39 -0700
+Subject: mm: shmem.c: Correctly annotate new inodes for lockdep
+
+From: Joel Fernandes (Google) <joel@joelfernandes.org>
+
+commit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream.
+
+Directories and inodes don't necessarily need to be in the same lockdep
+class. For ex, hugetlbfs splits them out too to prevent false positives
+in lockdep. Annotate correctly after new inode creation. If its a
+directory inode, it will be put into a different class.
+
+This should fix a lockdep splat reported by syzbot:
+
+> ======================================================
+> WARNING: possible circular locking dependency detected
+> 4.18.0-rc8-next-20180810+ #36 Not tainted
+> ------------------------------------------------------
+> syz-executor900/4483 is trying to acquire lock:
+> 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock
+> include/linux/fs.h:765 [inline]
+> 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at:
+> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
+>
+> but task is already holding lock:
+> 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
+> drivers/staging/android/ashmem.c:448
+>
+> which lock already depends on the new lock.
+>
+> -> #2 (ashmem_mutex){+.+.}:
+> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
+> __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
+> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
+> ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
+> call_mmap include/linux/fs.h:1844 [inline]
+> mmap_region+0xf27/0x1c50 mm/mmap.c:1762
+> do_mmap+0xa10/0x1220 mm/mmap.c:1535
+> do_mmap_pgoff include/linux/mm.h:2298 [inline]
+> vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
+> ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
+> __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
+> __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
+> __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
+> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
+> entry_SYSCALL_64_after_hwframe+0x49/0xbe
+>
+> -> #1 (&mm->mmap_sem){++++}:
+> __might_fault+0x155/0x1e0 mm/memory.c:4568
+> _copy_to_user+0x30/0x110 lib/usercopy.c:25
+> copy_to_user include/linux/uaccess.h:155 [inline]
+> filldir+0x1ea/0x3a0 fs/readdir.c:196
+> dir_emit_dot include/linux/fs.h:3464 [inline]
+> dir_emit_dots include/linux/fs.h:3475 [inline]
+> dcache_readdir+0x13a/0x620 fs/libfs.c:193
+> iterate_dir+0x48b/0x5d0 fs/readdir.c:51
+> __do_sys_getdents fs/readdir.c:231 [inline]
+> __se_sys_getdents fs/readdir.c:212 [inline]
+> __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
+> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
+> entry_SYSCALL_64_after_hwframe+0x49/0xbe
+>
+> -> #0 (&sb->s_type->i_mutex_key#9){++++}:
+> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
+> down_write+0x8f/0x130 kernel/locking/rwsem.c:70
+> inode_lock include/linux/fs.h:765 [inline]
+> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
+> ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
+> ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
+> vfs_ioctl fs/ioctl.c:46 [inline]
+> file_ioctl fs/ioctl.c:501 [inline]
+> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
+> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
+> __do_sys_ioctl fs/ioctl.c:709 [inline]
+> __se_sys_ioctl fs/ioctl.c:707 [inline]
+> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
+> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
+> entry_SYSCALL_64_after_hwframe+0x49/0xbe
+>
+> other info that might help us debug this:
+>
+> Chain exists of:
+> &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
+>
+> Possible unsafe locking scenario:
+>
+> CPU0 CPU1
+> ---- ----
+> lock(ashmem_mutex);
+> lock(&mm->mmap_sem);
+> lock(ashmem_mutex);
+> lock(&sb->s_type->i_mutex_key#9);
+>
+> *** DEADLOCK ***
+>
+> 1 lock held by syz-executor900/4483:
+> #0: 0000000025208078 (ashmem_mutex){+.+.}, at:
+> ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448
+
+Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org
+Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Reviewed-by: NeilBrown <neilb@suse.com>
+Suggested-by: NeilBrown <neilb@suse.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/shmem.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -1454,6 +1454,8 @@ static struct inode *shmem_get_inode(str
+ mpol_shared_policy_init(&info->policy, NULL);
+ break;
+ }
++
++ lockdep_annotate_inode_mutex_key(inode);
+ } else
+ shmem_free_inode(sb);
+ return inode;
--- /dev/null
+From 83f365554e47997ec68dc4eca3f5dce525cd15c3 Mon Sep 17 00:00:00 2001
+From: Vaibhav Nagarnaik <vnagarnaik@google.com>
+Date: Fri, 7 Sep 2018 15:31:29 -0700
+Subject: ring-buffer: Allow for rescheduling when removing pages
+
+From: Vaibhav Nagarnaik <vnagarnaik@google.com>
+
+commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream.
+
+When reducing ring buffer size, pages are removed by scheduling a work
+item on each CPU for the corresponding CPU ring buffer. After the pages
+are removed from ring buffer linked list, the pages are free()d in a
+tight loop. The loop does not give up CPU until all pages are removed.
+In a worst case behavior, when lot of pages are to be freed, it can
+cause system stall.
+
+After the pages are removed from the list, the free() can happen while
+the work is rescheduled. Call cond_resched() in the loop to prevent the
+system hangup.
+
+Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com
+
+Cc: stable@vger.kernel.org
+Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")
+Reported-by: Jason Behmer <jbehmer@google.com>
+Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/ring_buffer.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1542,6 +1542,8 @@ rb_remove_pages(struct ring_buffer_per_c
+ tmp_iter_page = first_page;
+
+ do {
++ cond_resched();
++
+ to_remove_page = tmp_iter_page;
+ rb_inc_page(cpu_buffer, &tmp_iter_page);
+
--- /dev/null
+asoc-cs4265-fix-mmtlr-data-switch-control.patch
+alsa-bebob-use-address-returned-by-kmalloc-instead-of-kernel-stack-for-streaming-dma-mapping.patch
+alsa-emu10k1-fix-possible-info-leak-to-userspace-on-sndrv_emu10k1_ioctl_info.patch
+ring-buffer-allow-for-rescheduling-when-removing-pages.patch
+mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
