spin_lock_irq(&runtime->lock);
+ if (runtime->buffer_ref) {
+ spin_unlock_irq(&runtime->lock);
-+ kvfree(newbuf);
++ kfree(newbuf);
+ return -EBUSY;
+ }
oldbuf = runtime->buffer;
--- /dev/null
+From 5a7b44a8df822e0667fc76ed7130252523993bda Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 3 Sep 2018 15:16:43 +0200
+Subject: ALSA: rawmidi: Initialize allocated buffers
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 5a7b44a8df822e0667fc76ed7130252523993bda upstream.
+
+syzbot reported the uninitialized value exposure in certain situations
+using virmidi loop. It's likely a very small race at writing and
+reading, and the influence is almost negligible. But it's safer to
+paper over this just by replacing the existing kvmalloc() with
+kvzalloc().
+
+Reported-by: syzbot+194dffdb8b22fc5d207a@syzkaller.appspotmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/rawmidi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/core/rawmidi.c
++++ b/sound/core/rawmidi.c
+@@ -125,7 +125,7 @@ static int snd_rawmidi_runtime_create(st
+ runtime->avail = 0;
+ else
+ runtime->avail = runtime->buffer_size;
+- if ((runtime->buffer = kmalloc(runtime->buffer_size, GFP_KERNEL)) == NULL) {
++ if ((runtime->buffer = kzalloc(runtime->buffer_size, GFP_KERNEL)) == NULL) {
+ kfree(runtime);
+ return -ENOMEM;
+ }
+@@ -650,7 +650,7 @@ int snd_rawmidi_output_params(struct snd
+ return -EINVAL;
+ }
+ if (params->buffer_size != runtime->buffer_size) {
+- newbuf = kmalloc(params->buffer_size, GFP_KERNEL);
++ newbuf = kzalloc(params->buffer_size, GFP_KERNEL);
+ if (!newbuf)
+ return -ENOMEM;
+ spin_lock_irq(&runtime->lock);
--- /dev/null
+From 0caf34350a25907515d929a9c77b9b206aac6d1e Mon Sep 17 00:00:00 2001
+From: Fabio Estevam <festevam@gmail.com>
+Date: Fri, 27 Mar 2020 10:36:24 -0300
+Subject: ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
+
+From: Fabio Estevam <festevam@gmail.com>
+
+commit 0caf34350a25907515d929a9c77b9b206aac6d1e upstream.
+
+The I2C2 pins are already used and the following errors are seen:
+
+imx27-pinctrl 10015000.iomuxc: pin MX27_PAD_I2C2_SDA already requested by 10012000.i2c; cannot claim for 1001d000.i2c
+imx27-pinctrl 10015000.iomuxc: pin-69 (1001d000.i2c) status -22
+imx27-pinctrl 10015000.iomuxc: could not request pin 69 (MX27_PAD_I2C2_SDA) from group i2c2grp on device 10015000.iomuxc
+imx-i2c 1001d000.i2c: Error applying setting, reverse things back
+imx-i2c: probe of 1001d000.i2c failed with error -22
+
+Fix it by adding the correct I2C1 IOMUX entries for the pinctrl_i2c1 group.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 61664d0b432a ("ARM: dts: imx27 phyCARD-S pinctrl")
+Signed-off-by: Fabio Estevam <festevam@gmail.com>
+Reviewed-by: Stefan Riedmueller <s.riedmueller@phytec.de>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
++++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
+@@ -81,8 +81,8 @@
+ imx27-phycard-s-rdk {
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+- MX27_PAD_I2C2_SDA__I2C2_SDA 0x0
+- MX27_PAD_I2C2_SCL__I2C2_SCL 0x0
++ MX27_PAD_I2C_DATA__I2C_DATA 0x0
++ MX27_PAD_I2C_CLK__I2C_CLK 0x0
+ >;
+ };
+
--- /dev/null
+From f87d1c9559164294040e58f5e3b74a162bf7c6e8 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Sat, 16 May 2020 16:29:20 -0500
+Subject: exec: Move would_dump into flush_old_exec
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit f87d1c9559164294040e58f5e3b74a162bf7c6e8 upstream.
+
+I goofed when I added mm->user_ns support to would_dump. I missed the
+fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and
+binfmt_script bprm->file is reassigned. Which made the move of
+would_dump from setup_new_exec to __do_execve_file before exec_binprm
+incorrect as it can result in would_dump running on the script instead
+of the interpreter of the script.
+
+The net result is that the code stopped making unreadable interpreters
+undumpable. Which allows them to be ptraced and written to disk
+without special permissions. Oops.
+
+The move was necessary because the call in set_new_exec was after
+bprm->mm was no longer valid.
+
+To correct this mistake move the misplaced would_dump from
+__do_execve_file into flos_old_exec, before exec_mmap is called.
+
+I tested and confirmed that without this fix I can attach with gdb to
+a script with an unreadable interpreter, and with this fix I can not.
+
+Cc: stable@vger.kernel.org
+Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files")
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exec.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -1270,6 +1270,8 @@ int flush_old_exec(struct linux_binprm *
+ */
+ set_mm_exe_file(bprm->mm, bprm->file);
+
++ would_dump(bprm, bprm->file);
++
+ /*
+ * Release all of the old mmap stuff
+ */
+@@ -1780,8 +1782,6 @@ static int do_execveat_common(int fd, st
+ if (retval < 0)
+ goto out;
+
+- would_dump(bprm, bprm->file);
+-
+ retval = exec_binprm(bprm);
+ if (retval < 0)
+ goto out;
net-ipv4-really-enforce-backoff-for-redirects.patch
netprio_cgroup-fix-unlimited-memory-leak-of-v2-cgroups.patch
alsa-hda-realtek-limit-int-mic-boost-for-thinkpad-t530.patch
+alsa-rawmidi-initialize-allocated-buffers.patch
alsa-rawmidi-fix-racy-buffer-resize-under-concurrent-accesses.patch
alsa-usb-audio-add-control-message-quirk-delay-for-kingston-hyperx-headset.patch
+usb-gadget-fix-illegal-array-access-in-binding-with-udc.patch
+usb-xhci-fix-null-pointer-dereference-when-enqueuing-trbs-from-urb-sg-list.patch
+arm-dts-imx27-phytec-phycard-s-rdk-fix-the-i2c1-pinctrl-entries.patch
+x86-fix-early-boot-crash-on-gcc-10-third-try.patch
+exec-move-would_dump-into-flush_old_exec.patch
--- /dev/null
+From 15753588bcd4bbffae1cca33c8ced5722477fe1f Mon Sep 17 00:00:00 2001
+From: Kyungtae Kim <kt0755@gmail.com>
+Date: Sun, 10 May 2020 05:43:34 +0000
+Subject: USB: gadget: fix illegal array access in binding with UDC
+
+From: Kyungtae Kim <kt0755@gmail.com>
+
+commit 15753588bcd4bbffae1cca33c8ced5722477fe1f upstream.
+
+FuzzUSB (a variant of syzkaller) found an illegal array access
+using an incorrect index while binding a gadget with UDC.
+
+Reference: https://www.spinics.net/lists/linux-usb/msg194331.html
+
+This bug occurs when a size variable used for a buffer
+is misused to access its strcpy-ed buffer.
+Given a buffer along with its size variable (taken from user input),
+from which, a new buffer is created using kstrdup().
+Due to the original buffer containing 0 value in the middle,
+the size of the kstrdup-ed buffer becomes smaller than that of the original.
+So accessing the kstrdup-ed buffer with the same size variable
+triggers memory access violation.
+
+The fix makes sure no zero value in the buffer,
+by comparing the strlen() of the orignal buffer with the size variable,
+so that the access to the kstrdup-ed buffer is safe.
+
+BUG: KASAN: slab-out-of-bounds in gadget_dev_desc_UDC_store+0x1ba/0x200
+drivers/usb/gadget/configfs.c:266
+Read of size 1 at addr ffff88806a55dd7e by task syz-executor.0/17208
+
+CPU: 2 PID: 17208 Comm: syz-executor.0 Not tainted 5.6.8 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xce/0x128 lib/dump_stack.c:118
+ print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
+ __kasan_report+0x131/0x1b0 mm/kasan/report.c:506
+ kasan_report+0x12/0x20 mm/kasan/common.c:641
+ __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132
+ gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266
+ flush_write_buffer fs/configfs/file.c:251 [inline]
+ configfs_write_file+0x2f1/0x4c0 fs/configfs/file.c:283
+ __vfs_write+0x85/0x110 fs/read_write.c:494
+ vfs_write+0x1cd/0x510 fs/read_write.c:558
+ ksys_write+0x18a/0x220 fs/read_write.c:611
+ __do_sys_write fs/read_write.c:623 [inline]
+ __se_sys_write fs/read_write.c:620 [inline]
+ __x64_sys_write+0x73/0xb0 fs/read_write.c:620
+ do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Signed-off-by: Kyungtae Kim <kt0755@gmail.com>
+Reported-and-tested-by: Kyungtae Kim <kt0755@gmail.com>
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200510054326.GA19198@pizza01
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/configfs.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/gadget/configfs.c
++++ b/drivers/usb/gadget/configfs.c
+@@ -259,6 +259,9 @@ static ssize_t gadget_dev_desc_UDC_store
+ char *name;
+ int ret;
+
++ if (strlen(page) < len)
++ return -EOVERFLOW;
++
+ name = kstrdup(page, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
--- /dev/null
+From 3c6f8cb92c9178fc0c66b580ea3df1fa3ac1155a Mon Sep 17 00:00:00 2001
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+Date: Thu, 14 May 2020 14:04:31 +0300
+Subject: usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg list
+
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+
+commit 3c6f8cb92c9178fc0c66b580ea3df1fa3ac1155a upstream.
+
+On platforms with IOMMU enabled, multiple SGs can be coalesced into one
+by the IOMMU driver. In that case the SG list processing as part of the
+completion of a urb on a bulk endpoint can result into a NULL pointer
+dereference with the below stack dump.
+
+<6> Unable to handle kernel NULL pointer dereference at virtual address 0000000c
+<6> pgd = c0004000
+<6> [0000000c] *pgd=00000000
+<6> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
+<2> PC is at xhci_queue_bulk_tx+0x454/0x80c
+<2> LR is at xhci_queue_bulk_tx+0x44c/0x80c
+<2> pc : [<c08907c4>] lr : [<c08907bc>] psr: 000000d3
+<2> sp : ca337c80 ip : 00000000 fp : ffffffff
+<2> r10: 00000000 r9 : 50037000 r8 : 00004000
+<2> r7 : 00000000 r6 : 00004000 r5 : 00000000 r4 : 00000000
+<2> r3 : 00000000 r2 : 00000082 r1 : c2c1a200 r0 : 00000000
+<2> Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
+<2> Control: 10c0383d Table: b412c06a DAC: 00000051
+<6> Process usb-storage (pid: 5961, stack limit = 0xca336210)
+<snip>
+<2> [<c08907c4>] (xhci_queue_bulk_tx)
+<2> [<c0881b3c>] (xhci_urb_enqueue)
+<2> [<c0831068>] (usb_hcd_submit_urb)
+<2> [<c08350b4>] (usb_sg_wait)
+<2> [<c089f384>] (usb_stor_bulk_transfer_sglist)
+<2> [<c089f2c0>] (usb_stor_bulk_srb)
+<2> [<c089fe38>] (usb_stor_Bulk_transport)
+<2> [<c089f468>] (usb_stor_invoke_transport)
+<2> [<c08a11b4>] (usb_stor_control_thread)
+<2> [<c014a534>] (kthread)
+
+The above NULL pointer dereference is the result of block_len and the
+sent_len set to zero after the first SG of the list when IOMMU driver
+is enabled. Because of this the loop of processing the SGs has run
+more than num_sgs which resulted in a sg_next on the last SG of the
+list which has SG_END set.
+
+Fix this by check for the sg before any attributes of the sg are
+accessed.
+
+[modified reason for null pointer dereference in commit message subject -Mathias]
+Fixes: f9c589e142d04 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20200514110432.25564-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-ring.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -3347,8 +3347,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *
+ /* New sg entry */
+ --num_sgs;
+ sent_len -= block_len;
+- if (num_sgs != 0) {
+- sg = sg_next(sg);
++ sg = sg_next(sg);
++ if (num_sgs != 0 && sg) {
+ block_len = sg_dma_len(sg);
+ addr = (u64) sg_dma_address(sg);
+ addr += sent_len;
--- /dev/null
+From a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Wed, 22 Apr 2020 18:11:30 +0200
+Subject: x86: Fix early boot crash on gcc-10, third try
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Borislav Petkov <bp@suse.de>
+
+commit a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e upstream.
+
+... or the odyssey of trying to disable the stack protector for the
+function which generates the stack canary value.
+
+The whole story started with Sergei reporting a boot crash with a kernel
+built with gcc-10:
+
+ Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary
+ CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139
+ Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013
+ Call Trace:
+ dump_stack
+ panic
+ ? start_secondary
+ __stack_chk_fail
+ start_secondary
+ secondary_startup_64
+ -—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary
+
+This happens because gcc-10 tail-call optimizes the last function call
+in start_secondary() - cpu_startup_entry() - and thus emits a stack
+canary check which fails because the canary value changes after the
+boot_init_stack_canary() call.
+
+To fix that, the initial attempt was to mark the one function which
+generates the stack canary with:
+
+ __attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
+
+however, using the optimize attribute doesn't work cumulatively
+as the attribute does not add to but rather replaces previously
+supplied optimization options - roughly all -fxxx options.
+
+The key one among them being -fno-omit-frame-pointer and thus leading to
+not present frame pointer - frame pointer which the kernel needs.
+
+The next attempt to prevent compilers from tail-call optimizing
+the last function call cpu_startup_entry(), shy of carving out
+start_secondary() into a separate compilation unit and building it with
+-fno-stack-protector, was to add an empty asm("").
+
+This current solution was short and sweet, and reportedly, is supported
+by both compilers but we didn't get very far this time: future (LTO?)
+optimization passes could potentially eliminate this, which leads us
+to the third attempt: having an actual memory barrier there which the
+compiler cannot ignore or move around etc.
+
+That should hold for a long time, but hey we said that about the other
+two solutions too so...
+
+Reported-by: Sergei Trofimovich <slyfox@gentoo.org>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Tested-by: Kalle Valo <kvalo@codeaurora.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/stackprotector.h | 7 ++++++-
+ arch/x86/kernel/smpboot.c | 8 ++++++++
+ arch/x86/xen/smp.c | 1 +
+ include/linux/compiler.h | 7 +++++++
+ init/main.c | 2 ++
+ 5 files changed, 24 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/stackprotector.h
++++ b/arch/x86/include/asm/stackprotector.h
+@@ -54,8 +54,13 @@
+ /*
+ * Initialize the stackprotector canary value.
+ *
+- * NOTE: this must only be called from functions that never return,
++ * NOTE: this must only be called from functions that never return
+ * and it must always be inlined.
++ *
++ * In addition, it should be called from a compilation unit for which
++ * stack protector is disabled. Alternatively, the caller should not end
++ * with a function call which gets tail-call optimized as that would
++ * lead to checking a modified canary value.
+ */
+ static __always_inline void boot_init_stack_canary(void)
+ {
+--- a/arch/x86/kernel/smpboot.c
++++ b/arch/x86/kernel/smpboot.c
+@@ -249,6 +249,14 @@ static void notrace start_secondary(void
+
+ wmb();
+ cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
++
++ /*
++ * Prevent tail call to cpu_startup_entry() because the stack protector
++ * guard has been changed a couple of function calls up, in
++ * boot_init_stack_canary() and must not be checked before tail calling
++ * another function.
++ */
++ prevent_tail_call_optimization();
+ }
+
+ /**
+--- a/arch/x86/xen/smp.c
++++ b/arch/x86/xen/smp.c
+@@ -116,6 +116,7 @@ asmlinkage __visible void cpu_bringup_an
+ #endif
+ cpu_bringup();
+ cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
++ prevent_tail_call_optimization();
+ }
+
+ void xen_smp_intr_free(unsigned int cpu)
+--- a/include/linux/compiler.h
++++ b/include/linux/compiler.h
+@@ -605,4 +605,11 @@ unsigned long read_word_at_a_time(const
+ # define __kprobes
+ # define nokprobe_inline inline
+ #endif
++
++/*
++ * This is needed in functions which generate the stack canary, see
++ * arch/x86/kernel/smpboot.c::start_secondary() for an example.
++ */
++#define prevent_tail_call_optimization() mb()
++
+ #endif /* __LINUX_COMPILER_H */
+--- a/init/main.c
++++ b/init/main.c
+@@ -662,6 +662,8 @@ asmlinkage __visible void __init start_k
+
+ /* Do the rest non-__init'ed, we're now alive */
+ rest_init();
++
++ prevent_tail_call_optimization();
+ }
+
+ /* Call all constructor functions linked into the kernel. */
projects / thirdparty / kernel / stable-queue.git / commitdiff
