From: Greg Kroah-Hartman Date: Wed, 26 Sep 2018 11:06:37 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.18.11~27 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=44faebc3937d485920ebac664d4beb0800a403c8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: 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 asoc-cs4265-fix-mmtlr-data-switch-control.patch mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch nfc-fix-possible-memory-corruption-when-handling-shdlc-i-frame-commands.patch nfc-fix-the-number-of-pipes.patch platform-x86-alienware-wmi-correct-a-memory-leak.patch ring-buffer-allow-for-rescheduling-when-removing-pages.patch xen-netfront-don-t-bug-in-case-of-too-many-frags.patch xen-x86-vpmu-zero-struct-pt_regs-before-calling-into-sample-handling-code.patch --- diff --git a/queue-4.4/alsa-bebob-use-address-returned-by-kmalloc-instead-of-kernel-stack-for-streaming-dma-mapping.patch b/queue-4.4/alsa-bebob-use-address-returned-by-kmalloc-instead-of-kernel-stack-for-streaming-dma-mapping.patch new file mode 100644 index 00000000000..6725ca1bea1 --- /dev/null +++ b/queue-4.4/alsa-bebob-use-address-returned-by-kmalloc-instead-of-kernel-stack-for-streaming-dma-mapping.patch @@ -0,0 +1,86 @@ +From 493626f2d87a74e6dbea1686499ed6e7e600484e Mon Sep 17 00:00:00 2001 +From: Takashi Sakamoto +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 + +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: # v3.16+ +Signed-off-by: Takashi Sakamoto +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/alsa-emu10k1-fix-possible-info-leak-to-userspace-on-sndrv_emu10k1_ioctl_info.patch b/queue-4.4/alsa-emu10k1-fix-possible-info-leak-to-userspace-on-sndrv_emu10k1_ioctl_info.patch new file mode 100644 index 00000000000..5639033be61 --- /dev/null +++ b/queue-4.4/alsa-emu10k1-fix-possible-info-leak-to-userspace-on-sndrv_emu10k1_ioctl_info.patch @@ -0,0 +1,37 @@ +From 49434c6c575d2008c0abbc93e615019f39e01252 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +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 + +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 +Cc: Jann Horn +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -2520,7 +2520,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); diff --git a/queue-4.4/asoc-cs4265-fix-mmtlr-data-switch-control.patch b/queue-4.4/asoc-cs4265-fix-mmtlr-data-switch-control.patch new file mode 100644 index 00000000000..c1530374ce4 --- /dev/null +++ b/queue-4.4/asoc-cs4265-fix-mmtlr-data-switch-control.patch @@ -0,0 +1,38 @@ +From 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?= + +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 + +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 +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -157,8 +157,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), + }; diff --git a/queue-4.4/mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch b/queue-4.4/mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch new file mode 100644 index 00000000000..114feae4858 --- /dev/null +++ b/queue-4.4/mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch @@ -0,0 +1,128 @@ +From b45d71fb89ab8adfe727b9d0ee188ed58582a647 Mon Sep 17 00:00:00 2001 +From: "Joel Fernandes (Google)" +Date: Thu, 20 Sep 2018 12:22:39 -0700 +Subject: mm: shmem.c: Correctly annotate new inodes for lockdep + +From: Joel Fernandes (Google) + +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) +Reported-by: syzbot +Reviewed-by: NeilBrown +Suggested-by: NeilBrown +Cc: Matthew Wilcox +Cc: Peter Zijlstra +Cc: Hugh Dickins +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman + +--- + mm/shmem.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/shmem.c ++++ b/mm/shmem.c +@@ -1464,6 +1464,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; diff --git a/queue-4.4/nfc-fix-possible-memory-corruption-when-handling-shdlc-i-frame-commands.patch b/queue-4.4/nfc-fix-possible-memory-corruption-when-handling-shdlc-i-frame-commands.patch new file mode 100644 index 00000000000..f6cb6c488eb --- /dev/null +++ b/queue-4.4/nfc-fix-possible-memory-corruption-when-handling-shdlc-i-frame-commands.patch @@ -0,0 +1,63 @@ +From 674d9de02aa7d521ebdf66c3958758bdd9c64e11 Mon Sep 17 00:00:00 2001 +From: Suren Baghdasaryan +Date: Mon, 17 Sep 2018 15:51:40 +0200 +Subject: NFC: Fix possible memory corruption when handling SHDLC I-Frame commands + +From: Suren Baghdasaryan + +commit 674d9de02aa7d521ebdf66c3958758bdd9c64e11 upstream. + +When handling SHDLC I-Frame commands "pipe" field used for indexing +into an array should be checked before usage. If left unchecked it +might access memory outside of the array of size NFC_HCI_MAX_PIPES(127). + +Malformed NFC HCI frames could be injected by a malicious NFC device +communicating with the device being attacked (remote attack vector), +or even by an attacker with physical access to the I2C bus such that +they could influence the data transfers on that bus (local attack vector). +skb->data is controlled by the attacker and has only been sanitized in +the most trivial ways (CRC check), therefore we can consider the +create_info struct and all of its members to tainted. 'create_info->pipe' +with max value of 255 (uint8) is used to take an offset of the +hdev->pipes array of 127 elements which can lead to OOB write. + +Cc: Samuel Ortiz +Cc: Allen Pais +Cc: "David S. Miller" +Suggested-by: Kevin Deus +Signed-off-by: Suren Baghdasaryan +Acked-by: Kees Cook +Cc: stable +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/nfc/hci/core.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/net/nfc/hci/core.c ++++ b/net/nfc/hci/core.c +@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci + } + create_info = (struct hci_create_pipe_resp *)skb->data; + ++ if (create_info->pipe >= NFC_HCI_MAX_PIPES) { ++ status = NFC_HCI_ANY_E_NOK; ++ goto exit; ++ } ++ + /* Save the new created pipe and bind with local gate, + * the description for skb->data[3] is destination gate id + * but since we received this cmd from host controller, we +@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci + } + delete_info = (struct hci_delete_pipe_noti *)skb->data; + ++ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) { ++ status = NFC_HCI_ANY_E_NOK; ++ goto exit; ++ } ++ + hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE; + hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST; + break; diff --git a/queue-4.4/nfc-fix-the-number-of-pipes.patch b/queue-4.4/nfc-fix-the-number-of-pipes.patch new file mode 100644 index 00000000000..dda4fe050a2 --- /dev/null +++ b/queue-4.4/nfc-fix-the-number-of-pipes.patch @@ -0,0 +1,45 @@ +From e285d5bfb7e9785d289663baef252dd315e171f8 Mon Sep 17 00:00:00 2001 +From: Suren Baghdasaryan +Date: Mon, 17 Sep 2018 15:51:41 +0200 +Subject: NFC: Fix the number of pipes + +From: Suren Baghdasaryan + +commit e285d5bfb7e9785d289663baef252dd315e171f8 upstream. + +According to ETSI TS 102 622 specification chapter 4.4 pipe identifier +is 7 bits long which allows for 128 unique pipe IDs. Because +NFC_HCI_MAX_PIPES is used as the number of pipes supported and not +as the max pipe ID, its value should be 128 instead of 127. + +nfc_hci_recv_from_llc extracts pipe ID from packet header using +NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127. +Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With +pipes array having only 127 elements and pipe ID of 127 the OOB memory +access will result. + +Cc: Samuel Ortiz +Cc: Allen Pais +Cc: "David S. Miller" +Suggested-by: Dan Carpenter +Signed-off-by: Suren Baghdasaryan +Reviewed-by: Kees Cook +Cc: stable +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + include/net/nfc/hci.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/net/nfc/hci.h ++++ b/include/net/nfc/hci.h +@@ -87,7 +87,7 @@ struct nfc_hci_pipe { + * According to specification 102 622 chapter 4.4 Pipes, + * the pipe identifier is 7 bits long. + */ +-#define NFC_HCI_MAX_PIPES 127 ++#define NFC_HCI_MAX_PIPES 128 + struct nfc_hci_init_data { + u8 gate_count; + struct nfc_hci_gate gates[NFC_HCI_MAX_CUSTOM_GATES]; diff --git a/queue-4.4/platform-x86-alienware-wmi-correct-a-memory-leak.patch b/queue-4.4/platform-x86-alienware-wmi-correct-a-memory-leak.patch new file mode 100644 index 00000000000..0e59aaf4af6 --- /dev/null +++ b/queue-4.4/platform-x86-alienware-wmi-correct-a-memory-leak.patch @@ -0,0 +1,30 @@ +From ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Mon, 10 Sep 2018 13:01:53 -0500 +Subject: platform/x86: alienware-wmi: Correct a memory leak + +From: Mario Limonciello + +commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream. + +An ACPI buffer that was allocated was not being freed after use. + +Signed-off-by: Mario Limonciello +Cc: stable@vger.kernel.org +Signed-off-by: Darren Hart (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/alienware-wmi.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/platform/x86/alienware-wmi.c ++++ b/drivers/platform/x86/alienware-wmi.c +@@ -463,6 +463,7 @@ static acpi_status alienware_hdmi_comman + if (obj && obj->type == ACPI_TYPE_INTEGER) + *out_data = (u32) obj->integer.value; + } ++ kfree(output.pointer); + return status; + + } diff --git a/queue-4.4/ring-buffer-allow-for-rescheduling-when-removing-pages.patch b/queue-4.4/ring-buffer-allow-for-rescheduling-when-removing-pages.patch new file mode 100644 index 00000000000..ee761f981e0 --- /dev/null +++ b/queue-4.4/ring-buffer-allow-for-rescheduling-when-removing-pages.patch @@ -0,0 +1,44 @@ +From 83f365554e47997ec68dc4eca3f5dce525cd15c3 Mon Sep 17 00:00:00 2001 +From: Vaibhav Nagarnaik +Date: Fri, 7 Sep 2018 15:31:29 -0700 +Subject: ring-buffer: Allow for rescheduling when removing pages + +From: Vaibhav Nagarnaik + +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 +Signed-off-by: Vaibhav Nagarnaik +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ring_buffer.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -1513,6 +1513,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); + diff --git a/queue-4.4/series b/queue-4.4/series new file mode 100644 index 00000000000..274d971fa64 --- /dev/null +++ b/queue-4.4/series @@ -0,0 +1,10 @@ +nfc-fix-possible-memory-corruption-when-handling-shdlc-i-frame-commands.patch +nfc-fix-the-number-of-pipes.patch +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 +platform-x86-alienware-wmi-correct-a-memory-leak.patch +xen-netfront-don-t-bug-in-case-of-too-many-frags.patch +xen-x86-vpmu-zero-struct-pt_regs-before-calling-into-sample-handling-code.patch +ring-buffer-allow-for-rescheduling-when-removing-pages.patch +mm-shmem.c-correctly-annotate-new-inodes-for-lockdep.patch diff --git a/queue-4.4/xen-netfront-don-t-bug-in-case-of-too-many-frags.patch b/queue-4.4/xen-netfront-don-t-bug-in-case-of-too-many-frags.patch new file mode 100644 index 00000000000..62dfba78098 --- /dev/null +++ b/queue-4.4/xen-netfront-don-t-bug-in-case-of-too-many-frags.patch @@ -0,0 +1,51 @@ +From ad4f15dc2c70b1de5e0a64d27335962fbc9cf71c Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Tue, 11 Sep 2018 09:04:48 +0200 +Subject: xen/netfront: don't bug in case of too many frags + +From: Juergen Gross + +commit ad4f15dc2c70b1de5e0a64d27335962fbc9cf71c upstream. + +Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in +xennet_get_responses()") raised the max number of allowed slots by one. +This seems to be problematic in some configurations with netback using +a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS +defined as 18 instead of nowadays 17). + +Instead of BUG_ON() in this case just fall back to retransmission. + +Fixes: 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()") +Cc: stable@vger.kernel.org +Signed-off-by: Juergen Gross +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/xen-netfront.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -892,7 +892,11 @@ static RING_IDX xennet_fill_frags(struct + BUG_ON(pull_to <= skb_headlen(skb)); + __pskb_pull_tail(skb, pull_to - skb_headlen(skb)); + } +- BUG_ON(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS); ++ if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) { ++ queue->rx.rsp_cons = ++cons; ++ kfree_skb(nskb); ++ return ~0U; ++ } + + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + skb_frag_page(nfrag), +@@ -1029,6 +1033,8 @@ err: + skb->len += rx->status; + + i = xennet_fill_frags(queue, skb, &tmpq); ++ if (unlikely(i == ~0U)) ++ goto err; + + if (rx->flags & XEN_NETRXF_csum_blank) + skb->ip_summed = CHECKSUM_PARTIAL; diff --git a/queue-4.4/xen-x86-vpmu-zero-struct-pt_regs-before-calling-into-sample-handling-code.patch b/queue-4.4/xen-x86-vpmu-zero-struct-pt_regs-before-calling-into-sample-handling-code.patch new file mode 100644 index 00000000000..b0f1c0fce59 --- /dev/null +++ b/queue-4.4/xen-x86-vpmu-zero-struct-pt_regs-before-calling-into-sample-handling-code.patch @@ -0,0 +1,33 @@ +From 70513d58751d7c6c1a0133557b13089b9f2e3e66 Mon Sep 17 00:00:00 2001 +From: Boris Ostrovsky +Date: Thu, 12 Jul 2018 13:27:00 -0400 +Subject: xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code + +From: Boris Ostrovsky + +commit 70513d58751d7c6c1a0133557b13089b9f2e3e66 upstream. + +Otherwise we may leak kernel stack for events that sample user +registers. + +Reported-by: Mark Rutland +Reviewed-by: Juergen Gross +Signed-off-by: Boris Ostrovsky +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/pmu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/xen/pmu.c ++++ b/arch/x86/xen/pmu.c +@@ -477,7 +477,7 @@ static void xen_convert_regs(const struc + irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id) + { + int err, ret = IRQ_NONE; +- struct pt_regs regs; ++ struct pt_regs regs = {0}; + const struct xen_pmu_data *xenpmu_data = get_xenpmu_data(); + uint8_t xenpmu_flags = get_xenpmu_flags(); +