platform-x86-toshiba_acpi-fix-the-wrong-variable-ass.patch
can-m_can-fix-nominal-bitiming-tseg2-min-for-version.patch
perf-probe-fix-to-die_entrypc-returns-error-correctl.patch
+usb-core-change-pk-for-__user-pointers-to-px.patch
+usb-gadget-f_midi-fix-memleak-in-f_midi_alloc.patch
+usb-gadget-fix-memleak-in-gadgetfs_fill_super.patch
+x86-speculation-fix-prctl-when-spectre_v2_user-seccomp-prctl-ibpb.patch
--- /dev/null
+From f3bc432aa8a7a2bfe9ebb432502be5c5d979d7fe Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 19 Nov 2020 12:02:28 -0500
+Subject: USB: core: Change %pK for __user pointers to %px
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit f3bc432aa8a7a2bfe9ebb432502be5c5d979d7fe upstream.
+
+Commit 2f964780c03b ("USB: core: replace %p with %pK") used the %pK
+format specifier for a bunch of __user pointers. But as the 'K' in
+the specifier indicates, it is meant for kernel pointers. The reason
+for the %pK specifier is to avoid leaks of kernel addresses, but when
+the pointer is to an address in userspace the security implications
+are minimal. In particular, no kernel information is leaked.
+
+This patch changes the __user %pK specifiers (used in a bunch of
+debugging output lines) to %px, which will always print the actual
+address with no mangling. (Notably, there is no printk format
+specifier particularly intended for __user pointers.)
+
+Fixes: 2f964780c03b ("USB: core: replace %p with %pK")
+CC: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20201119170228.GB576844@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/devio.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/core/devio.c
++++ b/drivers/usb/core/devio.c
+@@ -478,11 +478,11 @@ static void snoop_urb(struct usb_device
+
+ if (userurb) { /* Async */
+ if (when == SUBMIT)
+- dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
++ dev_info(&udev->dev, "userurb %px, ep%d %s-%s, "
+ "length %u\n",
+ userurb, ep, t, d, length);
+ else
+- dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
++ dev_info(&udev->dev, "userurb %px, ep%d %s-%s, "
+ "actual_length %u status %d\n",
+ userurb, ep, t, d, length,
+ timeout_or_status);
+@@ -1946,7 +1946,7 @@ static int proc_reapurb(struct usb_dev_s
+ if (as) {
+ int retval;
+
+- snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
++ snoop(&ps->dev->dev, "reap %px\n", as->userurb);
+ retval = processcompl(as, (void __user * __user *)arg);
+ free_async(as);
+ return retval;
+@@ -1963,7 +1963,7 @@ static int proc_reapurbnonblock(struct u
+
+ as = async_getcompleted(ps);
+ if (as) {
+- snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
++ snoop(&ps->dev->dev, "reap %px\n", as->userurb);
+ retval = processcompl(as, (void __user * __user *)arg);
+ free_async(as);
+ } else {
+@@ -2089,7 +2089,7 @@ static int proc_reapurb_compat(struct us
+ if (as) {
+ int retval;
+
+- snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
++ snoop(&ps->dev->dev, "reap %px\n", as->userurb);
+ retval = processcompl_compat(as, (void __user * __user *)arg);
+ free_async(as);
+ return retval;
+@@ -2106,7 +2106,7 @@ static int proc_reapurbnonblock_compat(s
+
+ as = async_getcompleted(ps);
+ if (as) {
+- snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
++ snoop(&ps->dev->dev, "reap %px\n", as->userurb);
+ retval = processcompl_compat(as, (void __user * __user *)arg);
+ free_async(as);
+ } else {
+@@ -2531,7 +2531,7 @@ static long usbdev_do_ioctl(struct file
+ #endif
+
+ case USBDEVFS_DISCARDURB:
+- snoop(&dev->dev, "%s: DISCARDURB %pK\n", __func__, p);
++ snoop(&dev->dev, "%s: DISCARDURB %px\n", __func__, p);
+ ret = proc_unlinkurb(ps, p);
+ break;
+
--- /dev/null
+From e7694cb6998379341fd9bf3bd62b48c4e6a79385 Mon Sep 17 00:00:00 2001
+From: Zhang Qilong <zhangqilong3@huawei.com>
+Date: Tue, 17 Nov 2020 10:16:28 +0800
+Subject: usb: gadget: f_midi: Fix memleak in f_midi_alloc
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+commit e7694cb6998379341fd9bf3bd62b48c4e6a79385 upstream.
+
+In the error path, if midi is not null, we should
+free the midi->id if necessary to prevent memleak.
+
+Fixes: b85e9de9e818d ("usb: gadget: f_midi: convert to new function interface with backward compatibility")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Link: https://lore.kernel.org/r/20201117021629.1470544-2-zhangqilong3@huawei.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/function/f_midi.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/gadget/function/f_midi.c
++++ b/drivers/usb/gadget/function/f_midi.c
+@@ -1303,7 +1303,7 @@ static struct usb_function *f_midi_alloc
+ midi->id = kstrdup(opts->id, GFP_KERNEL);
+ if (opts->id && !midi->id) {
+ status = -ENOMEM;
+- goto setup_fail;
++ goto midi_free;
+ }
+ midi->in_ports = opts->in_ports;
+ midi->out_ports = opts->out_ports;
+@@ -1315,7 +1315,7 @@ static struct usb_function *f_midi_alloc
+
+ status = kfifo_alloc(&midi->in_req_fifo, midi->qlen, GFP_KERNEL);
+ if (status)
+- goto setup_fail;
++ goto midi_free;
+
+ spin_lock_init(&midi->transmit_lock);
+
+@@ -1331,9 +1331,13 @@ static struct usb_function *f_midi_alloc
+
+ return &midi->func;
+
++midi_free:
++ if (midi)
++ kfree(midi->id);
++ kfree(midi);
+ setup_fail:
+ mutex_unlock(&opts->lock);
+- kfree(midi);
++
+ return ERR_PTR(status);
+ }
+
--- /dev/null
+From 87bed3d7d26c974948a3d6e7176f304b2d41272b Mon Sep 17 00:00:00 2001
+From: Zhang Qilong <zhangqilong3@huawei.com>
+Date: Tue, 17 Nov 2020 10:16:29 +0800
+Subject: usb: gadget: Fix memleak in gadgetfs_fill_super
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+commit 87bed3d7d26c974948a3d6e7176f304b2d41272b upstream.
+
+usb_get_gadget_udc_name will alloc memory for CHIP
+in "Enomem" branch. we should free it before error
+returns to prevent memleak.
+
+Fixes: 175f712119c57 ("usb: gadget: provide interface for legacy gadgets to get UDC name")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Link: https://lore.kernel.org/r/20201117021629.1470544-3-zhangqilong3@huawei.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/legacy/inode.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/gadget/legacy/inode.c
++++ b/drivers/usb/gadget/legacy/inode.c
+@@ -2044,6 +2044,9 @@ gadgetfs_fill_super (struct super_block
+ return 0;
+
+ Enomem:
++ kfree(CHIP);
++ CHIP = NULL;
++
+ return -ENOMEM;
+ }
+
--- /dev/null
+From 33fc379df76b4991e5ae312f07bcd6820811971e Mon Sep 17 00:00:00 2001
+From: Anand K Mistry <amistry@google.com>
+Date: Tue, 10 Nov 2020 12:33:53 +1100
+Subject: x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
+
+From: Anand K Mistry <amistry@google.com>
+
+commit 33fc379df76b4991e5ae312f07bcd6820811971e upstream.
+
+When spectre_v2_user={seccomp,prctl},ibpb is specified on the command
+line, IBPB is force-enabled and STIPB is conditionally-enabled (or not
+available).
+
+However, since
+
+ 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
+
+the spectre_v2_user_ibpb variable is set to SPECTRE_V2_USER_{PRCTL,SECCOMP}
+instead of SPECTRE_V2_USER_STRICT, which is the actual behaviour.
+Because the issuing of IBPB relies on the switch_mm_*_ibpb static
+branches, the mitigations behave as expected.
+
+Since
+
+ 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
+
+this discrepency caused the misreporting of IB speculation via prctl().
+
+On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb,
+prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL |
+PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are
+always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB
+speculation mode, even though the flag is ignored.
+
+Similarly, for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should
+also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not
+available.
+
+ [ bp: Massage commit message. ]
+
+Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
+Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
+Signed-off-by: Anand K Mistry <amistry@google.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/bugs.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/bugs.c
++++ b/arch/x86/kernel/cpu/bugs.c
+@@ -733,11 +733,13 @@ spectre_v2_user_select_mitigation(enum s
+ if (boot_cpu_has(X86_FEATURE_IBPB)) {
+ setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
+
++ spectre_v2_user_ibpb = mode;
+ switch (cmd) {
+ case SPECTRE_V2_USER_CMD_FORCE:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
+ static_branch_enable(&switch_mm_always_ibpb);
++ spectre_v2_user_ibpb = SPECTRE_V2_USER_STRICT;
+ break;
+ case SPECTRE_V2_USER_CMD_PRCTL:
+ case SPECTRE_V2_USER_CMD_AUTO:
+@@ -751,8 +753,6 @@ spectre_v2_user_select_mitigation(enum s
+ pr_info("mitigation: Enabling %s Indirect Branch Prediction Barrier\n",
+ static_key_enabled(&switch_mm_always_ibpb) ?
+ "always-on" : "conditional");
+-
+- spectre_v2_user_ibpb = mode;
+ }
+
+ /*
projects / thirdparty / kernel / stable-queue.git / commitdiff
