2021-06-14 10:40:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 00/49] 4.14.237-rc1 review

This is the start of the stable review cycle for the 4.14.237 release.
There are 49 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 16 Jun 2021 10:26:30 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.237-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.14.237-rc1

Liangyan <[email protected]>
tracing: Correct the length check which causes memory corruption

Steven Rostedt (VMware) <[email protected]>
ftrace: Do not blindly read the ip address in ftrace_bug()

Ming Lei <[email protected]>
scsi: core: Only put parent device if host state differs from SHOST_CREATED

Ming Lei <[email protected]>
scsi: core: Put .shost_dev in failure path if host state changes to RUNNING

Ming Lei <[email protected]>
scsi: core: Fix error handling of scsi_host_alloc()

Dai Ngo <[email protected]>
NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.

Anna Schumaker <[email protected]>
NFS: Fix use-after-free in nfs4_init_client()

Paolo Bonzini <[email protected]>
kvm: fix previous commit for 32-bit builds

Leo Yan <[email protected]>
perf session: Correct buffer copying when peeking events

Dan Carpenter <[email protected]>
NFS: Fix a potential NULL dereference in nfs_get_client()

Marco Elver <[email protected]>
perf: Fix data race between pin_count increment/decrement

Dmitry Osipenko <[email protected]>
regulator: max77620: Use device_set_of_node_from_dev()

Dmitry Baryshkov <[email protected]>
regulator: core: resolve supply for boot-on/always-on regulators

Maciej Żenczykowski <[email protected]>
usb: fix various gadget panics on 10gbps cabling

Maciej Żenczykowski <[email protected]>
usb: fix various gadgets null ptr deref on 10gbps cabling.

Linyu Yuan <[email protected]>
usb: gadget: eem: fix wrong eem header operation

Johan Hovold <[email protected]>
USB: serial: quatech2: fix control-request directions

Alexandre GRIVEAUX <[email protected]>
USB: serial: omninet: add device id for Zyxel Omni 56K Plus

George McCollister <[email protected]>
USB: serial: ftdi_sio: add NovaTech OrionMX product ID

Wesley Cheng <[email protected]>
usb: gadget: f_fs: Ensure io_completion_wq is idle during unbind

Mayank Rana <[email protected]>
usb: typec: ucsi: Clear PPM capability data in ucsi_init() error path

Marian-Cristian Rotariu <[email protected]>
usb: dwc3: ep0: fix NULL pointer exception

Maciej Żenczykowski <[email protected]>
USB: f_ncm: ncm_bitrate (speed) is unsigned

Alexander Kuznetsov <[email protected]>
cgroup1: don't allow '\n' in renaming

Ritesh Harjani <[email protected]>
btrfs: return value from btrfs_mark_extent_written() in case of error

Wenli Looi <[email protected]>
staging: rtl8723bs: Fix uninitialized variables

Paolo Bonzini <[email protected]>
kvm: avoid speculation-based attacks from out-of-range memslot accesses

Desmond Cheong Zhi Xi <[email protected]>
drm: Lock pointer access in drm_master_release()

Desmond Cheong Zhi Xi <[email protected]>
drm: Fix use-after-free read in drm_getunique()

Chris Packham <[email protected]>
i2c: mpc: implement erratum A-004447 workaround

Chris Packham <[email protected]>
i2c: mpc: Make use of i2c_recover_bus()

Chris Packham <[email protected]>
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers

Chris Packham <[email protected]>
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers

Jiapeng Chong <[email protected]>
bnx2x: Fix missing error code in bnx2x_iov_init_one()

Tiezhu Yang <[email protected]>
MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACER

Saubhik Mukherjee <[email protected]>
net: appletalk: cops: Fix data race in cops_probe1

Zong Li <[email protected]>
net: macb: ensure the device is available before accessing GEMGXL control registers

Dmitry Bogdanov <[email protected]>
scsi: target: qla2xxx: Wait for stop_phase1 at WWN removal

Matt Wang <[email protected]>
scsi: vmw_pvscsi: Set correct residual data length

Zheyu Ma <[email protected]>
net/qla3xxx: fix schedule while atomic in ql_sem_spinlock

Sergey Senozhatsky <[email protected]>
wq: handle VM suspension in stall detection

Shakeel Butt <[email protected]>
cgroup: disable controllers at parse time

Dan Carpenter <[email protected]>
net: mdiobus: get rid of a BUG_ON()

Johannes Berg <[email protected]>
netlink: disable IRQs for netlink_lock_table()

Johannes Berg <[email protected]>
bonding: init notify_work earlier to avoid uninitialized use

Zheyu Ma <[email protected]>
isdn: mISDN: netjet: Fix crash in nj_probe:

Zou Wei <[email protected]>
ASoC: sti-sas: add missing MODULE_DEVICE_TABLE

Jeimon <[email protected]>
net/nfc/rawsock.c: fix a permission check bug

Kees Cook <[email protected]>
proc: Track /proc/$pid/attr/ opener mm_struct


-------------

Diffstat:

Makefile | 4 +-
arch/mips/lib/mips-atomic.c | 12 +--
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++
drivers/gpu/drm/drm_auth.c | 3 +-
drivers/gpu/drm/drm_ioctl.c | 9 ++-
drivers/i2c/busses/i2c-mpc.c | 95 ++++++++++++++++++++++-
drivers/isdn/hardware/mISDN/netjet.c | 1 -
drivers/net/appletalk/cops.c | 4 +-
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 4 +-
drivers/net/ethernet/cadence/macb_main.c | 3 +
drivers/net/ethernet/qlogic/qla3xxx.c | 2 +-
drivers/net/phy/mdio_bus.c | 3 +-
drivers/regulator/core.c | 6 ++
drivers/regulator/max77620-regulator.c | 7 ++
drivers/scsi/hosts.c | 33 ++++----
drivers/scsi/qla2xxx/qla_target.c | 2 +
drivers/scsi/vmw_pvscsi.c | 8 +-
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
drivers/usb/dwc3/ep0.c | 3 +
drivers/usb/gadget/config.c | 8 ++
drivers/usb/gadget/function/f_ecm.c | 2 +-
drivers/usb/gadget/function/f_eem.c | 6 +-
drivers/usb/gadget/function/f_fs.c | 3 +
drivers/usb/gadget/function/f_hid.c | 3 +-
drivers/usb/gadget/function/f_loopback.c | 2 +-
drivers/usb/gadget/function/f_ncm.c | 2 +-
drivers/usb/gadget/function/f_printer.c | 3 +-
drivers/usb/gadget/function/f_rndis.c | 2 +-
drivers/usb/gadget/function/f_serial.c | 2 +-
drivers/usb/gadget/function/f_sourcesink.c | 3 +-
drivers/usb/gadget/function/f_subset.c | 2 +-
drivers/usb/gadget/function/f_tcm.c | 3 +-
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
drivers/usb/serial/omninet.c | 2 +
drivers/usb/serial/quatech2.c | 6 +-
drivers/usb/typec/ucsi/ucsi.c | 1 +
fs/btrfs/file.c | 4 +-
fs/nfs/client.c | 2 +-
fs/nfs/nfs4client.c | 2 +-
fs/nfs/nfs4proc.c | 8 ++
fs/proc/base.c | 9 ++-
include/linux/kvm_host.h | 10 ++-
kernel/cgroup/cgroup-v1.c | 4 +
kernel/cgroup/cgroup.c | 13 ++--
kernel/events/core.c | 2 +
kernel/trace/ftrace.c | 8 +-
kernel/trace/trace.c | 2 +-
kernel/workqueue.c | 12 ++-
net/netlink/af_netlink.c | 6 +-
net/nfc/rawsock.c | 2 +-
sound/soc/codecs/sti-sas.c | 1 +
tools/perf/util/session.c | 1 +
55 files changed, 291 insertions(+), 74 deletions(-)



2021-06-14 10:41:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 02/49] net/nfc/rawsock.c: fix a permission check bug

From: Jeimon <[email protected]>

[ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ]

The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable().

Signed-off-by: Jeimon <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/nfc/rawsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c
index 57a07ab80d92..bdc72737fe24 100644
--- a/net/nfc/rawsock.c
+++ b/net/nfc/rawsock.c
@@ -345,7 +345,7 @@ static int rawsock_create(struct net *net, struct socket *sock,
return -ESOCKTNOSUPPORT;

if (sock->type == SOCK_RAW) {
- if (!capable(CAP_NET_RAW))
+ if (!ns_capable(net->user_ns, CAP_NET_RAW))
return -EPERM;
sock->ops = &rawsock_raw_ops;
} else {
--
2.30.2



2021-06-14 10:41:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 17/49] powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers

From: Chris Packham <[email protected]>

[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]

The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q (latest available at the time of writing).

Signed-off-by: Chris Packham <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index 51e975d7631a..8921f17fca42 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -389,7 +389,23 @@
};

/include/ "qoriq-i2c-0.dtsi"
+ i2c@118000 {
+ fsl,i2c-erratum-a004447;
+ };
+
+ i2c@118100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "qoriq-i2c-1.dtsi"
+ i2c@119000 {
+ fsl,i2c-erratum-a004447;
+ };
+
+ i2c@119100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "qoriq-duart-0.dtsi"
/include/ "qoriq-duart-1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
--
2.30.2



2021-06-14 10:41:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 06/49] netlink: disable IRQs for netlink_lock_table()

From: Johannes Berg <[email protected]>

[ Upstream commit 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d ]

Syzbot reports that in mac80211 we have a potential deadlock
between our "local->stop_queue_reasons_lock" (spinlock) and
netlink's nl_table_lock (rwlock). This is because there's at
least one situation in which we might try to send a netlink
message with this spinlock held while it is also possible to
take the spinlock from a hardirq context, resulting in the
following deadlock scenario reported by lockdep:

CPU0 CPU1
---- ----
lock(nl_table_lock);
local_irq_disable();
lock(&local->queue_stop_reason_lock);
lock(nl_table_lock);
<Interrupt>
lock(&local->queue_stop_reason_lock);

This seems valid, we can take the queue_stop_reason_lock in
any kind of context ("CPU0"), and call ieee80211_report_ack_skb()
with the spinlock held and IRQs disabled ("CPU1") in some
code path (ieee80211_do_stop() via ieee80211_free_txskb()).

Short of disallowing netlink use in scenarios like these
(which would be rather complex in mac80211's case due to
the deep callchain), it seems the only fix for this is to
disable IRQs while nl_table_lock is held to avoid hitting
this scenario, this disallows the "CPU0" portion of the
reported deadlock.

Note that the writer side (netlink_table_grab()) already
disables IRQs for this lock.

Unfortunately though, this seems like a huge hammer, and
maybe the whole netlink table locking should be reworked.

Reported-by: [email protected]
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/netlink/af_netlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 3e4e07559272..140bec3568ec 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -429,11 +429,13 @@ void netlink_table_ungrab(void)
static inline void
netlink_lock_table(void)
{
+ unsigned long flags;
+
/* read_lock() synchronizes us to netlink_table_grab */

- read_lock(&nl_table_lock);
+ read_lock_irqsave(&nl_table_lock, flags);
atomic_inc(&nl_table_users);
- read_unlock(&nl_table_lock);
+ read_unlock_irqrestore(&nl_table_lock, flags);
}

static inline void
--
2.30.2



2021-06-14 10:41:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 09/49] wq: handle VM suspension in stall detection

From: Sergey Senozhatsky <[email protected]>

[ Upstream commit 940d71c6462e8151c78f28e4919aa8882ff2054e ]

If VCPU is suspended (VM suspend) in wq_watchdog_timer_fn() then
once this VCPU resumes it will see the new jiffies value, while it
may take a while before IRQ detects PVCLOCK_GUEST_STOPPED on this
VCPU and updates all the watchdogs via pvclock_touch_watchdogs().
There is a small chance of misreported WQ stalls in the meantime,
because new jiffies is time_after() old 'ts + thresh'.

wq_watchdog_timer_fn()
{
for_each_pool(pool, pi) {
if (time_after(jiffies, ts + thresh)) {
pr_emerg("BUG: workqueue lockup - pool");
}
}
}

Save jiffies at the beginning of this function and use that value
for stall detection. If VM gets suspended then we continue using
"old" jiffies value and old WQ touch timestamps. If IRQ at some
point restarts the stall detection cycle (pvclock_touch_watchdogs())
then old jiffies will always be before new 'ts + thresh'.

Signed-off-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/workqueue.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index bc32ed4a4cf3..58e7eefe4dbf 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -49,6 +49,7 @@
#include <linux/moduleparam.h>
#include <linux/uaccess.h>
#include <linux/nmi.h>
+#include <linux/kvm_para.h>

#include "workqueue_internal.h"

@@ -5465,6 +5466,7 @@ static void wq_watchdog_timer_fn(unsigned long data)
{
unsigned long thresh = READ_ONCE(wq_watchdog_thresh) * HZ;
bool lockup_detected = false;
+ unsigned long now = jiffies;
struct worker_pool *pool;
int pi;

@@ -5479,6 +5481,12 @@ static void wq_watchdog_timer_fn(unsigned long data)
if (list_empty(&pool->worklist))
continue;

+ /*
+ * If a virtual machine is stopped by the host it can look to
+ * the watchdog like a stall.
+ */
+ kvm_check_and_clear_guest_paused();
+
/* get the latest of pool and touched timestamps */
pool_ts = READ_ONCE(pool->watchdog_ts);
touched = READ_ONCE(wq_watchdog_touched);
@@ -5497,12 +5505,12 @@ static void wq_watchdog_timer_fn(unsigned long data)
}

/* did we stall? */
- if (time_after(jiffies, ts + thresh)) {
+ if (time_after(now, ts + thresh)) {
lockup_detected = true;
pr_emerg("BUG: workqueue lockup - pool");
pr_cont_pool_info(pool);
pr_cont(" stuck for %us!\n",
- jiffies_to_msecs(jiffies - pool_ts) / 1000);
+ jiffies_to_msecs(now - pool_ts) / 1000);
}
}

--
2.30.2



2021-06-14 10:41:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 34/49] usb: gadget: eem: fix wrong eem header operation

From: Linyu Yuan <[email protected]>

commit 305f670846a31a261462577dd0b967c4fa796871 upstream.

when skb_clone() or skb_copy_expand() fail,
it should pull skb with lengh indicated by header,
or not it will read network data and check it as header.

Cc: <[email protected]>
Signed-off-by: Linyu Yuan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_eem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -502,7 +502,7 @@ static int eem_unwrap(struct gether *por
skb2 = skb_clone(skb, GFP_ATOMIC);
if (unlikely(!skb2)) {
DBG(cdev, "unable to unframe EEM packet\n");
- continue;
+ goto next;
}
skb_trim(skb2, len - ETH_FCS_LEN);

@@ -513,7 +513,7 @@ static int eem_unwrap(struct gether *por
if (unlikely(!skb3)) {
DBG(cdev, "unable to realign EEM packet\n");
dev_kfree_skb_any(skb2);
- continue;
+ goto next;
}
dev_kfree_skb_any(skb2);
skb_queue_tail(list, skb3);


2021-06-14 10:41:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 31/49] USB: serial: ftdi_sio: add NovaTech OrionMX product ID

From: George McCollister <[email protected]>

commit bc96c72df33ee81b24d87eab953c73f7bcc04f29 upstream.

Add PID for the NovaTech OrionMX so it can be automatically detected.

Signed-off-by: George McCollister <[email protected]>
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -606,6 +606,7 @@ static const struct usb_device_id id_tab
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLX_PLUS_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_NT_ORION_IO_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_NT_ORIONMX_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX2_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -581,6 +581,7 @@
#define FTDI_NT_ORIONLXM_PID 0x7c90 /* OrionLXm Substation Automation Platform */
#define FTDI_NT_ORIONLX_PLUS_PID 0x7c91 /* OrionLX+ Substation Automation Platform */
#define FTDI_NT_ORION_IO_PID 0x7c92 /* Orion I/O */
+#define FTDI_NT_ORIONMX_PID 0x7c93 /* OrionMX */

/*
* Synapse Wireless product ids (FTDI_VID)


2021-06-14 10:41:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 35/49] usb: fix various gadgets null ptr deref on 10gbps cabling.

From: Maciej Żenczykowski <[email protected]>

commit 90c4d05780d47e14a50e11a7f17373104cd47d25 upstream.

This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.

Fixes: eaef50c76057 ("usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus")
Cc: Christophe JAILLET <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Gustavo A. R. Silva <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: Michael R Sweet <[email protected]>
Cc: Mike Christie <[email protected]>
Cc: Pawel Laszczak <[email protected]>
Cc: Peter Chen <[email protected]>
Cc: Sudhakar Panneerselvam <[email protected]>
Cc: Wei Ming Chen <[email protected]>
Cc: Will McVicker <[email protected]>
Cc: Zqiang <[email protected]>
Reviewed-By: Lorenzo Colitti <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Maciej Żenczykowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_ecm.c | 2 +-
drivers/usb/gadget/function/f_eem.c | 2 +-
drivers/usb/gadget/function/f_hid.c | 3 ++-
drivers/usb/gadget/function/f_loopback.c | 2 +-
drivers/usb/gadget/function/f_printer.c | 3 ++-
drivers/usb/gadget/function/f_rndis.c | 2 +-
drivers/usb/gadget/function/f_serial.c | 2 +-
drivers/usb/gadget/function/f_sourcesink.c | 3 ++-
drivers/usb/gadget/function/f_subset.c | 2 +-
drivers/usb/gadget/function/f_tcm.c | 3 ++-
10 files changed, 14 insertions(+), 10 deletions(-)

--- a/drivers/usb/gadget/function/f_ecm.c
+++ b/drivers/usb/gadget/function/f_ecm.c
@@ -793,7 +793,7 @@ ecm_bind(struct usb_configuration *c, st
fs_ecm_notify_desc.bEndpointAddress;

status = usb_assign_descriptors(f, ecm_fs_function, ecm_hs_function,
- ecm_ss_function, NULL);
+ ecm_ss_function, ecm_ss_function);
if (status)
goto fail;

--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -309,7 +309,7 @@ static int eem_bind(struct usb_configura
eem_ss_out_desc.bEndpointAddress = eem_fs_out_desc.bEndpointAddress;

status = usb_assign_descriptors(f, eem_fs_function, eem_hs_function,
- eem_ss_function, NULL);
+ eem_ss_function, eem_ss_function);
if (status)
goto fail;

--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -812,7 +812,8 @@ static int hidg_bind(struct usb_configur
hidg_fs_out_ep_desc.bEndpointAddress;

status = usb_assign_descriptors(f, hidg_fs_descriptors,
- hidg_hs_descriptors, hidg_ss_descriptors, NULL);
+ hidg_hs_descriptors, hidg_ss_descriptors,
+ hidg_ss_descriptors);
if (status)
goto fail;

--- a/drivers/usb/gadget/function/f_loopback.c
+++ b/drivers/usb/gadget/function/f_loopback.c
@@ -211,7 +211,7 @@ autoconf_fail:
ss_loop_sink_desc.bEndpointAddress = fs_loop_sink_desc.bEndpointAddress;

ret = usb_assign_descriptors(f, fs_loopback_descs, hs_loopback_descs,
- ss_loopback_descs, NULL);
+ ss_loopback_descs, ss_loopback_descs);
if (ret)
return ret;

--- a/drivers/usb/gadget/function/f_printer.c
+++ b/drivers/usb/gadget/function/f_printer.c
@@ -1067,7 +1067,8 @@ autoconf_fail:
ss_ep_out_desc.bEndpointAddress = fs_ep_out_desc.bEndpointAddress;

ret = usb_assign_descriptors(f, fs_printer_function,
- hs_printer_function, ss_printer_function, NULL);
+ hs_printer_function, ss_printer_function,
+ ss_printer_function);
if (ret)
return ret;

--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -793,7 +793,7 @@ rndis_bind(struct usb_configuration *c,
ss_notify_desc.bEndpointAddress = fs_notify_desc.bEndpointAddress;

status = usb_assign_descriptors(f, eth_fs_function, eth_hs_function,
- eth_ss_function, NULL);
+ eth_ss_function, eth_ss_function);
if (status)
goto fail;

--- a/drivers/usb/gadget/function/f_serial.c
+++ b/drivers/usb/gadget/function/f_serial.c
@@ -236,7 +236,7 @@ static int gser_bind(struct usb_configur
gser_ss_out_desc.bEndpointAddress = gser_fs_out_desc.bEndpointAddress;

status = usb_assign_descriptors(f, gser_fs_function, gser_hs_function,
- gser_ss_function, NULL);
+ gser_ss_function, gser_ss_function);
if (status)
goto fail;
dev_dbg(&cdev->gadget->dev, "generic ttyGS%d: %s speed IN/%s OUT/%s\n",
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -435,7 +435,8 @@ no_iso:
ss_iso_sink_desc.bEndpointAddress = fs_iso_sink_desc.bEndpointAddress;

ret = usb_assign_descriptors(f, fs_source_sink_descs,
- hs_source_sink_descs, ss_source_sink_descs, NULL);
+ hs_source_sink_descs, ss_source_sink_descs,
+ ss_source_sink_descs);
if (ret)
return ret;

--- a/drivers/usb/gadget/function/f_subset.c
+++ b/drivers/usb/gadget/function/f_subset.c
@@ -362,7 +362,7 @@ geth_bind(struct usb_configuration *c, s
fs_subset_out_desc.bEndpointAddress;

status = usb_assign_descriptors(f, fs_eth_function, hs_eth_function,
- ss_eth_function, NULL);
+ ss_eth_function, ss_eth_function);
if (status)
goto fail;

--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -2071,7 +2071,8 @@ static int tcm_bind(struct usb_configura
uasp_fs_cmd_desc.bEndpointAddress = uasp_ss_cmd_desc.bEndpointAddress;

ret = usb_assign_descriptors(f, uasp_fs_function_desc,
- uasp_hs_function_desc, uasp_ss_function_desc, NULL);
+ uasp_hs_function_desc, uasp_ss_function_desc,
+ uasp_ss_function_desc);
if (ret)
goto ep_fail;



2021-06-14 10:42:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 36/49] usb: fix various gadget panics on 10gbps cabling

From: Maciej Żenczykowski <[email protected]>

commit 032e288097a553db5653af552dd8035cd2a0ba96 upstream.

usb_assign_descriptors() is called with 5 parameters,
the last 4 of which are the usb_descriptor_header for:
full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),
high-speed (USB2.0 - 480Mbps),
super-speed (USB3.0 - 5Gbps),
super-speed-plus (USB3.1 - 10Gbps).

The differences between full/high/super-speed descriptors are usually
substantial (due to changes in the maximum usb block size from 64 to 512
to 1024 bytes and other differences in the specs), while the difference
between 5 and 10Gbps descriptors may be as little as nothing
(in many cases the same tuning is simply good enough).

However if a gadget driver calls usb_assign_descriptors() with
a NULL descriptor for super-speed-plus and is then used on a max 10gbps
configuration, the kernel will crash with a null pointer dereference,
when a 10gbps capable device port + cable + host port combination shows up.
(This wouldn't happen if the gadget max-speed was set to 5gbps, but
it of course defaults to the maximum, and there's no real reason to
artificially limit it)

The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,
if a 10gbps descriptor wasn't provided.

Obviously this won't fix the problem if the 5gbps descriptor is also
NULL, but such cases can't be so trivially solved (and any such gadgets
are unlikely to be used with USB3 ports any way).

Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Maciej Żenczykowski <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/config.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/usb/gadget/config.c
+++ b/drivers/usb/gadget/config.c
@@ -168,6 +168,14 @@ int usb_assign_descriptors(struct usb_fu
{
struct usb_gadget *g = f->config->cdev->gadget;

+ /* super-speed-plus descriptor falls back to super-speed one,
+ * if such a descriptor was provided, thus avoiding a NULL
+ * pointer dereference if a 5gbps capable gadget is used with
+ * a 10gbps capable config (device port + cable + host port)
+ */
+ if (!ssp)
+ ssp = ss;
+
if (fs) {
f->fs_descriptors = usb_copy_descriptors(fs);
if (!f->fs_descriptors)


2021-06-14 10:42:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 20/49] i2c: mpc: implement erratum A-004447 workaround

From: Chris Packham <[email protected]>

[ Upstream commit 8f0cdec8b5fd94135d643662506ee94ae9e98785 ]

The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P2040 Chip Errata Rev Q.

Signed-off-by: Chris Packham <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/busses/i2c-mpc.c | 79 +++++++++++++++++++++++++++++++++++-
1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d94df068c073..7db5554d2b4e 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -23,6 +23,7 @@

#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/fsl_devices.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
@@ -49,6 +50,7 @@
#define CCR_MTX 0x10
#define CCR_TXAK 0x08
#define CCR_RSTA 0x04
+#define CCR_RSVD 0x02

#define CSR_MCF 0x80
#define CSR_MAAS 0x40
@@ -70,6 +72,7 @@ struct mpc_i2c {
u8 fdr, dfsrr;
#endif
struct clk *clk_per;
+ bool has_errata_A004447;
};

struct mpc_i2c_divider {
@@ -178,6 +181,75 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
return 0;
}

+static int i2c_mpc_wait_sr(struct mpc_i2c *i2c, int mask)
+{
+ void __iomem *addr = i2c->base + MPC_I2C_SR;
+ u8 val;
+
+ return readb_poll_timeout(addr, val, val & mask, 0, 100);
+}
+
+/*
+ * Workaround for Erratum A004447. From the P2040CE Rev Q
+ *
+ * 1. Set up the frequency divider and sampling rate.
+ * 2. I2CCR - a0h
+ * 3. Poll for I2CSR[MBB] to get set.
+ * 4. If I2CSR[MAL] is set (an indication that SDA is stuck low), then go to
+ * step 5. If MAL is not set, then go to step 13.
+ * 5. I2CCR - 00h
+ * 6. I2CCR - 22h
+ * 7. I2CCR - a2h
+ * 8. Poll for I2CSR[MBB] to get set.
+ * 9. Issue read to I2CDR.
+ * 10. Poll for I2CSR[MIF] to be set.
+ * 11. I2CCR - 82h
+ * 12. Workaround complete. Skip the next steps.
+ * 13. Issue read to I2CDR.
+ * 14. Poll for I2CSR[MIF] to be set.
+ * 15. I2CCR - 80h
+ */
+static void mpc_i2c_fixup_A004447(struct mpc_i2c *i2c)
+{
+ int ret;
+ u32 val;
+
+ writeccr(i2c, CCR_MEN | CCR_MSTA);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MBB);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MBB\n");
+ return;
+ }
+
+ val = readb(i2c->base + MPC_I2C_SR);
+
+ if (val & CSR_MAL) {
+ writeccr(i2c, 0x00);
+ writeccr(i2c, CCR_MSTA | CCR_RSVD);
+ writeccr(i2c, CCR_MEN | CCR_MSTA | CCR_RSVD);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MBB);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MBB\n");
+ return;
+ }
+ val = readb(i2c->base + MPC_I2C_DR);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MIF);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MIF\n");
+ return;
+ }
+ writeccr(i2c, CCR_MEN | CCR_RSVD);
+ } else {
+ val = readb(i2c->base + MPC_I2C_DR);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MIF);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MIF\n");
+ return;
+ }
+ writeccr(i2c, CCR_MEN);
+ }
+}
+
#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
@@ -636,7 +708,10 @@ static int fsl_i2c_bus_recovery(struct i2c_adapter *adap)
{
struct mpc_i2c *i2c = i2c_get_adapdata(adap);

- mpc_i2c_fixup(i2c);
+ if (i2c->has_errata_A004447)
+ mpc_i2c_fixup_A004447(i2c);
+ else
+ mpc_i2c_fixup(i2c);

return 0;
}
@@ -740,6 +815,8 @@ static int fsl_i2c_probe(struct platform_device *op)
dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 1000000 / HZ);

platform_set_drvdata(op, i2c);
+ if (of_property_read_bool(op->dev.of_node, "fsl,i2c-erratum-a004447"))
+ i2c->has_errata_A004447 = true;

i2c->adap = mpc_ops;
of_address_to_resource(op->dev.of_node, 0, &res);
--
2.30.2



2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 40/49] NFS: Fix a potential NULL dereference in nfs_get_client()

From: Dan Carpenter <[email protected]>

[ Upstream commit 09226e8303beeec10f2ff844d2e46d1371dc58e0 ]

None of the callers are expecting NULL returns from nfs_get_client() so
this code will lead to an Oops. It's better to return an error
pointer. I expect that this is dead code so hopefully no one is
affected.

Fixes: 31434f496abb ("nfs: check hostname in nfs_get_client")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/nfs/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 9e7d49fac4e3..1f74893b2b0c 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -406,7 +406,7 @@ struct nfs_client *nfs_get_client(const struct nfs_client_initdata *cl_init)

if (cl_init->hostname == NULL) {
WARN_ON(1);
- return NULL;
+ return ERR_PTR(-EINVAL);
}

/* see if the client already exists */
--
2.30.2



2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 43/49] NFS: Fix use-after-free in nfs4_init_client()

From: Anna Schumaker <[email protected]>

commit 476bdb04c501fc64bf3b8464ffddefc8dbe01577 upstream.

KASAN reports a use-after-free when attempting to mount two different
exports through two different NICs that belong to the same server.

Olga was able to hit this with kernels starting somewhere between 5.7
and 5.10, but I traced the patch that introduced the clear_bit() call to
4.13. So something must have changed in the refcounting of the clp
pointer to make this call to nfs_put_client() the very last one.

Fixes: 8dcbec6d20 ("NFSv41: Handle EXCHID4_FLAG_CONFIRMED_R during NFSv4.1 migration")
Cc: [email protected] # 4.13+
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -417,8 +417,8 @@ struct nfs_client *nfs4_init_client(stru
*/
nfs_mark_client_ready(clp, -EPERM);
}
- nfs_put_client(clp);
clear_bit(NFS_CS_TSM_POSSIBLE, &clp->cl_flags);
+ nfs_put_client(clp);
return old;

error:


2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 37/49] regulator: core: resolve supply for boot-on/always-on regulators

From: Dmitry Baryshkov <[email protected]>

commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream.

For the boot-on/always-on regulators the set_machine_constrainst() is
called before resolving rdev->supply. Thus the code would try to enable
rdev before enabling supplying regulator. Enforce resolving supply
regulator before enabling rdev.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/regulator/core.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1081,6 +1081,12 @@ static int set_machine_constraints(struc
* and we have control then make sure it is enabled.
*/
if (rdev->constraints->always_on || rdev->constraints->boot_on) {
+ /* If we want to enable this regulator, make sure that we know
+ * the supplying regulator.
+ */
+ if (rdev->supply_name && !rdev->supply)
+ return -EPROBE_DEFER;
+
ret = _regulator_do_enable(rdev);
if (ret < 0 && ret != -EINVAL) {
rdev_err(rdev, "failed to enable\n");


2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 45/49] scsi: core: Fix error handling of scsi_host_alloc()

From: Ming Lei <[email protected]>

commit 66a834d092930cf41d809c0e989b13cd6f9ca006 upstream.

After device is initialized via device_initialize(), or its name is set via
dev_set_name(), the device has to be freed via put_device(). Otherwise
device name will be leaked because it is allocated dynamically in
dev_set_name().

Fix the leak by replacing kfree() with put_device(). Since
scsi_host_dev_release() properly handles IDA and kthread removal, remove
special-casing these from the error handling as well.

Link: https://lore.kernel.org/r/[email protected]
Cc: Bart Van Assche <[email protected]>
Cc: John Garry <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Tested-by: John Garry <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/hosts.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)

--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -404,8 +404,10 @@ struct Scsi_Host *scsi_host_alloc(struct
mutex_init(&shost->scan_mutex);

index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
- if (index < 0)
- goto fail_kfree;
+ if (index < 0) {
+ kfree(shost);
+ return NULL;
+ }
shost->host_no = index;

shost->dma_channel = 0xff;
@@ -493,7 +495,7 @@ struct Scsi_Host *scsi_host_alloc(struct
shost_printk(KERN_WARNING, shost,
"error handler thread failed to spawn, error = %ld\n",
PTR_ERR(shost->ehandler));
- goto fail_index_remove;
+ goto fail;
}

shost->tmf_work_q = alloc_workqueue("scsi_tmf_%d",
@@ -502,17 +504,18 @@ struct Scsi_Host *scsi_host_alloc(struct
if (!shost->tmf_work_q) {
shost_printk(KERN_WARNING, shost,
"failed to create tmf workq\n");
- goto fail_kthread;
+ goto fail;
}
scsi_proc_hostdir_add(shost->hostt);
return shost;
+ fail:
+ /*
+ * Host state is still SHOST_CREATED and that is enough to release
+ * ->shost_gendev. scsi_host_dev_release() will free
+ * dev_name(&shost->shost_dev).
+ */
+ put_device(&shost->shost_gendev);

- fail_kthread:
- kthread_stop(shost->ehandler);
- fail_index_remove:
- ida_simple_remove(&host_index_ida, shost->host_no);
- fail_kfree:
- kfree(shost);
return NULL;
}
EXPORT_SYMBOL(scsi_host_alloc);


2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 44/49] NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.

From: Dai Ngo <[email protected]>

commit f8849e206ef52b584cd9227255f4724f0cc900bb upstream.

Currently if __nfs4_proc_set_acl fails with NFS4ERR_BADOWNER it
re-enables the idmapper by clearing NFS_CAP_UIDGID_NOMAP before
retrying again. The NFS_CAP_UIDGID_NOMAP remains cleared even if
the retry fails. This causes problem for subsequent setattr
requests for v4 server that does not have idmapping configured.

This patch modifies nfs4_proc_set_acl to detect NFS4ERR_BADOWNER
and NFS4ERR_BADNAME and skips the retry, since the kernel isn't
involved in encoding the ACEs, and return -EINVAL.

Steps to reproduce the problem:

# mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt
# touch /tmp/mnt/file1
# chown 99 /tmp/mnt/file1
# nfs4_setfacl -a A::[email protected]:wrtncy /tmp/mnt/file1
Failed setxattr operation: Invalid argument
# chown 99 /tmp/mnt/file1
chown: changing ownership of ‘/tmp/mnt/file1’: Invalid argument
# umount /tmp/mnt
# mount -o vers=4.1,sec=sys server:/export/test /tmp/mnt
# chown 99 /tmp/mnt/file1
#

v2: detect NFS4ERR_BADOWNER and NFS4ERR_BADNAME and skip retry
in nfs4_proc_set_acl.
Signed-off-by: Dai Ngo <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4proc.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5294,6 +5294,14 @@ static int nfs4_proc_set_acl(struct inod
do {
err = __nfs4_proc_set_acl(inode, buf, buflen);
trace_nfs4_set_acl(inode, err);
+ if (err == -NFS4ERR_BADOWNER || err == -NFS4ERR_BADNAME) {
+ /*
+ * no need to retry since the kernel
+ * isn't involved in encoding the ACEs.
+ */
+ err = -EINVAL;
+ break;
+ }
err = nfs4_handle_exception(NFS_SERVER(inode), err,
&exception);
} while (exception.retry);


2021-06-14 10:44:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 42/49] kvm: fix previous commit for 32-bit builds

From: Paolo Bonzini <[email protected]>

commit 4422829e8053068e0225e4d0ef42dc41ea7c9ef5 upstream.

array_index_nospec does not work for uint64_t on 32-bit builds.
However, the size of a memory slot must be less than 20 bits wide
on those system, since the memory slot must fit in the user
address space. So just store it in an unsigned long.

Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/kvm_host.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -969,8 +969,8 @@ __gfn_to_hva_memslot(struct kvm_memory_s
* table walks, do not let the processor speculate loads outside
* the guest's registered memslots.
*/
- unsigned long offset = array_index_nospec(gfn - slot->base_gfn,
- slot->npages);
+ unsigned long offset = gfn - slot->base_gfn;
+ offset = array_index_nospec(offset, slot->npages);
return slot->userspace_addr + offset * PAGE_SIZE;
}



2021-06-14 10:44:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 48/49] ftrace: Do not blindly read the ip address in ftrace_bug()

From: Steven Rostedt (VMware) <[email protected]>

commit 6c14133d2d3f768e0a35128faac8aa6ed4815051 upstream.

It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.

Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.

Link: https://lore.kernel.org/lkml/[email protected]/

Cc: [email protected]
Fixes: 05736a427f7e1 ("ftrace: warn on failure to disable mcount callers")
Reported-by: Mark-PK Tsai <[email protected]>
Tested-by: Mark-PK Tsai <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/ftrace.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2042,12 +2042,18 @@ static int ftrace_hash_ipmodify_update(s

static void print_ip_ins(const char *fmt, const unsigned char *p)
{
+ char ins[MCOUNT_INSN_SIZE];
int i;

+ if (probe_kernel_read(ins, p, MCOUNT_INSN_SIZE)) {
+ printk(KERN_CONT "%s[FAULT] %px\n", fmt, p);
+ return;
+ }
+
printk(KERN_CONT "%s", fmt);

for (i = 0; i < MCOUNT_INSN_SIZE; i++)
- printk(KERN_CONT "%s%02x", i ? ":" : "", p[i]);
+ printk(KERN_CONT "%s%02x", i ? ":" : "", ins[i]);
}

enum ftrace_bug_type ftrace_bug_type;


2021-06-14 10:45:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 22/49] drm: Lock pointer access in drm_master_release()

From: Desmond Cheong Zhi Xi <[email protected]>

commit c336a5ee984708db4826ef9e47d184e638e29717 upstream.

This patch eliminates the following smatch warning:
drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access 'master' (line 318) expected lock '&dev->master_mutex'

The 'file_priv->master' field should be protected by the mutex lock to
'&dev->master_mutex'. This is because other processes can concurrently
modify this field and free the current 'file_priv->master'
pointer. This could result in a use-after-free error when 'master' is
dereferenced in subsequent function calls to
'drm_legacy_lock_master_cleanup()' or to 'drm_lease_revoke()'.

An example of a scenario that would produce this error can be seen
from a similar bug in 'drm_getunique()' that was reported by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the Syzbot report, another process concurrently acquired the
device's master mutex in 'drm_setmaster_ioctl()', then overwrote
'fpriv->master' in 'drm_new_set_master()'. The old value of
'fpriv->master' was subsequently freed before the mutex was unlocked.

Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Desmond Cheong Zhi Xi <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/drm_auth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -244,9 +244,10 @@ int drm_master_open(struct drm_file *fil
void drm_master_release(struct drm_file *file_priv)
{
struct drm_device *dev = file_priv->minor->dev;
- struct drm_master *master = file_priv->master;
+ struct drm_master *master;

mutex_lock(&dev->master_mutex);
+ master = file_priv->master;
if (file_priv->magic)
idr_remove(&file_priv->master->magic_map, file_priv->magic);



2021-06-14 10:45:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 49/49] tracing: Correct the length check which causes memory corruption

From: Liangyan <[email protected]>

commit 3e08a9f9760f4a70d633c328a76408e62d6f80a3 upstream.

We've suffered from severe kernel crashes due to memory corruption on
our production environment, like,

Call Trace:
[1640542.554277] general protection fault: 0000 [#1] SMP PTI
[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
0000000006e931bf
[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
ffff9a45ff004300
[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
0000000000000000
[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffff9a20608d
[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
696c662f65636976
[1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
knlGS:0000000000000000
[1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
00000000003606e0
[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[1640542.566742] Call Trace:
[1640542.567009] anon_vma_clone+0x5d/0x170
[1640542.567417] __split_vma+0x91/0x1a0
[1640542.567777] do_munmap+0x2c6/0x320
[1640542.568128] vm_munmap+0x54/0x70
[1640542.569990] __x64_sys_munmap+0x22/0x30
[1640542.572005] do_syscall_64+0x5b/0x1b0
[1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1640542.575642] RIP: 0033:0x7f45d6e61e27

James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[ 86.780806] no_context+0xdf/0x3c0
[ 86.784327] __do_page_fault+0x252/0x470
[ 86.788367] do_page_fault+0x32/0x140
[ 86.792145] page_fault+0x1e/0x30
[ 86.795576] strncpy_from_unsafe+0x66/0xb0
[ 86.799789] fetch_memory_string+0x25/0x40
[ 86.804002] fetch_deref_string+0x51/0x60
[ 86.808134] kprobe_trace_func+0x32d/0x3a0
[ 86.812347] kprobe_dispatcher+0x45/0x50
[ 86.816385] kprobe_ftrace_handler+0x90/0xf0
[ 86.820779] ftrace_ops_assist_func+0xa1/0x140
[ 86.825340] 0xffffffffc00750bf
[ 86.828603] do_sys_open+0x5/0x1f0
[ 86.832124] do_syscall_64+0x5b/0x1b0
[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9

commit b220c049d519 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry->array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow.

Link: https://lkml.kernel.org/r/[email protected]

Cc: [email protected]
Cc: Ingo Molnar <[email protected]>
Cc: Xunlei Pang <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer")
Reviewed-by: Xunlei Pang <[email protected]>
Reviewed-by: yinbinbin <[email protected]>
Reviewed-by: Wetp Zhang <[email protected]>
Tested-by: James Wang <[email protected]>
Signed-off-by: Liangyan <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2274,7 +2274,7 @@ trace_event_buffer_lock_reserve(struct r
(entry = this_cpu_read(trace_buffered_event))) {
/* Try to use the per cpu buffer first */
val = this_cpu_inc_return(trace_buffered_event_cnt);
- if ((len < (PAGE_SIZE - sizeof(*entry))) && val == 1) {
+ if ((len < (PAGE_SIZE - sizeof(*entry) - sizeof(entry->array[0]))) && val == 1) {
trace_event_setup(entry, type, flags, pc);
entry->array[0] = len;
return entry;


2021-06-14 10:45:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 24/49] staging: rtl8723bs: Fix uninitialized variables

From: Wenli Looi <[email protected]>

commit 43c85d770db80cb135f576f8fde6ff1a08e707a4 upstream.

The sinfo.pertid and sinfo.generation variables are not initialized and
it causes a crash when we use this as a wireless access point.

[ 456.873025] ------------[ cut here ]------------
[ 456.878198] kernel BUG at mm/slub.c:3968!
[ 456.882680] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM

[ snip ]

[ 457.271004] Backtrace:
[ 457.273733] [<c02b7ee4>] (kfree) from [<c0e2a470>] (nl80211_send_station+0x954/0xfc4)
[ 457.282481] r9:eccca0c0 r8:e8edfec0 r7:00000000 r6:00000011 r5:e80a9480 r4:e8edfe00
[ 457.291132] [<c0e29b1c>] (nl80211_send_station) from [<c0e2b18c>] (cfg80211_new_sta+0x90/0x1cc)
[ 457.300850] r10:e80a9480 r9:e8edfe00 r8:ea678cca r7:00000a20 r6:00000000 r5:ec46d000
[ 457.309586] r4:ec46d9e0
[ 457.312433] [<c0e2b0fc>] (cfg80211_new_sta) from [<bf086684>] (rtw_cfg80211_indicate_sta_assoc+0x80/0x9c [r8723bs])
[ 457.324095] r10:00009930 r9:e85b9d80 r8:bf091050 r7:00000000 r6:00000000 r5:0000001c
[ 457.332831] r4:c1606788
[ 457.335692] [<bf086604>] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [<bf03df38>] (rtw_stassoc_event_callback+0x1c8/0x1d4 [r8723bs])
[ 457.349489] r7:ea678cc0 r6:000000a1 r5:f1225f84 r4:f086b000
[ 457.355845] [<bf03dd70>] (rtw_stassoc_event_callback [r8723bs]) from [<bf048e4c>] (mlme_evt_hdl+0x8c/0xb4 [r8723bs])
[ 457.367601] r7:c1604900 r6:f086c4b8 r5:00000000 r4:f086c000
[ 457.373959] [<bf048dc0>] (mlme_evt_hdl [r8723bs]) from [<bf03693c>] (rtw_cmd_thread+0x198/0x3d8 [r8723bs])
[ 457.384744] r5:f086e000 r4:f086c000
[ 457.388754] [<bf0367a4>] (rtw_cmd_thread [r8723bs]) from [<c014a214>] (kthread+0x170/0x174)
[ 457.398083] r10:ed7a57e8 r9:bf0367a4 r8:f086b000 r7:e8ede000 r6:00000000 r5:e9975200
[ 457.406828] r4:e8369900
[ 457.409653] [<c014a0a4>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[ 457.417718] Exception stack(0xe8edffb0 to 0xe8edfff8)
[ 457.423356] ffa0: 00000000 00000000 00000000 00000000
[ 457.432492] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 457.441618] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 457.449006] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a0a4
[ 457.457750] r4:e9975200
[ 457.460574] Code: 1a000003 e5953004 e3130001 1a000000 (e7f001f2)
[ 457.467381] ---[ end trace 4acbc8c15e9e6aa7 ]---

Link: https://forum.armbian.com/topic/14727-wifi-ap-kernel-bug-in-kernel-5444/
Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info")
Fixes: f5ea9120be2e ("nl80211: add generation number to all dumps")
Signed-off-by: Wenli Looi <[email protected]>
Reviewed-by: Dan Carpenter <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -2432,7 +2432,7 @@ void rtw_cfg80211_indicate_sta_assoc(str
DBG_871X(FUNC_ADPT_FMT"\n", FUNC_ADPT_ARG(padapter));

{
- struct station_info sinfo;
+ struct station_info sinfo = {};
u8 ie_offset;
if (GetFrameSubType(pmgmt_frame) == WIFI_ASSOCREQ)
ie_offset = _ASOCREQ_IE_OFFSET_;


2021-06-14 10:45:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 23/49] kvm: avoid speculation-based attacks from out-of-range memslot accesses

From: Paolo Bonzini <[email protected]>

commit da27a83fd6cc7780fea190e1f5c19e87019da65c upstream.

KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot. The translation is
performed in __gfn_to_hva_memslot using the following formula:

hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guest's
physical memory. However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.

__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva. If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.

Right now it's not clear if there are any cases in which this is
exploitable. One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86. Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier. However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space. Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets. Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached. This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.

Reported-by: Artemiy Margaritov <[email protected]>
Co-developed-by: Artemiy Margaritov <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/kvm_host.h | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -963,7 +963,15 @@ __gfn_to_memslot(struct kvm_memslots *sl
static inline unsigned long
__gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
{
- return slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE;
+ /*
+ * The index was checked originally in search_memslots. To avoid
+ * that a malicious guest builds a Spectre gadget out of e.g. page
+ * table walks, do not let the processor speculate loads outside
+ * the guest's registered memslots.
+ */
+ unsigned long offset = array_index_nospec(gfn - slot->base_gfn,
+ slot->npages);
+ return slot->userspace_addr + offset * PAGE_SIZE;
}

static inline int memslot_id(struct kvm *kvm, gfn_t gfn)


2021-06-14 10:46:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 38/49] regulator: max77620: Use device_set_of_node_from_dev()

From: Dmitry Osipenko <[email protected]>

commit 6f55c5dd1118b3076d11d9cb17f5c5f4bc3a1162 upstream.

The MAX77620 driver fails to re-probe on deferred probe because driver
core tries to claim resources that are already claimed by the PINCTRL
device. Use device_set_of_node_from_dev() helper which marks OF node as
reused, skipping erroneous execution of pinctrl_bind_pins() for the PMIC
device on the re-probe.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/regulator/max77620-regulator.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/regulator/max77620-regulator.c
+++ b/drivers/regulator/max77620-regulator.c
@@ -792,6 +792,13 @@ static int max77620_regulator_probe(stru
config.dev = dev;
config.driver_data = pmic;

+ /*
+ * Set of_node_reuse flag to prevent driver core from attempting to
+ * claim any pinmux resources already claimed by the parent device.
+ * Otherwise PMIC driver will fail to re-probe.
+ */
+ device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent);
+
for (id = 0; id < MAX77620_NUM_REGS; id++) {
struct regulator_dev *rdev;
struct regulator_desc *rdesc;


2021-06-14 10:46:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 26/49] cgroup1: dont allow \n in renaming

From: Alexander Kuznetsov <[email protected]>

commit b7e24eb1caa5f8da20d405d262dba67943aedc42 upstream.

cgroup_mkdir() have restriction on newline usage in names:
$ mkdir $'/sys/fs/cgroup/cpu/test\ntest2'
mkdir: cannot create directory
'/sys/fs/cgroup/cpu/test\ntest2': Invalid argument

But in cgroup1_rename() such check is missed.
This allows us to make /proc/<pid>/cgroup unparsable:
$ mkdir /sys/fs/cgroup/cpu/test
$ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2'
$ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2'
$ cat /proc/self/cgroup
11:pids:/
10:freezer:/
9:hugetlb:/
8:cpuset:/
7:blkio:/user.slice
6:memory:/user.slice
5:net_cls,net_prio:/
4:perf_event:/
3:devices:/user.slice
2:cpu,cpuacct:/test
test2
1:name=systemd:/
0::/

Signed-off-by: Alexander Kuznetsov <[email protected]>
Reported-by: Andrey Krasichkov <[email protected]>
Acked-by: Dmitry Yakunin <[email protected]>
Cc: [email protected]
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/cgroup/cgroup-v1.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -861,6 +861,10 @@ static int cgroup1_rename(struct kernfs_
struct cgroup *cgrp = kn->priv;
int ret;

+ /* do not accept '\n' to prevent making /proc/<pid>/cgroup unparsable */
+ if (strchr(new_name_str, '\n'))
+ return -EINVAL;
+
if (kernfs_type(kn) != KERNFS_DIR)
return -ENOTDIR;
if (kn->parent != new_parent)


2021-06-14 10:46:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 25/49] btrfs: return value from btrfs_mark_extent_written() in case of error

From: Ritesh Harjani <[email protected]>

commit e7b2ec3d3d4ebeb4cff7ae45cf430182fa6a49fb upstream.

We always return 0 even in case of an error in btrfs_mark_extent_written().
Fix it to return proper error value in case of a failure. All callers
handle it.

CC: [email protected] # 4.4+
Signed-off-by: Ritesh Harjani <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1100,7 +1100,7 @@ int btrfs_mark_extent_written(struct btr
int del_nr = 0;
int del_slot = 0;
int recow;
- int ret;
+ int ret = 0;
u64 ino = btrfs_ino(inode);

path = btrfs_alloc_path();
@@ -1320,7 +1320,7 @@ again:
}
out:
btrfs_free_path(path);
- return 0;
+ return ret;
}

/*


2021-06-14 10:46:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 27/49] USB: f_ncm: ncm_bitrate (speed) is unsigned

From: Maciej Żenczykowski <[email protected]>

commit 3370139745853f7826895293e8ac3aec1430508e upstream.

[ 190.544755] configfs-gadget gadget: notify speed -44967296

This is because 4250000000 - 2**32 is -44967296.

Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
Cc: Brooke Basile <[email protected]>
Cc: Bryan O'Donoghue <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Cc: Yauheni Kaliuta <[email protected]>
Cc: Linux USB Mailing List <[email protected]>
Acked-By: Lorenzo Colitti <[email protected]>
Signed-off-by: Maciej Żenczykowski <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -589,7 +589,7 @@ static void ncm_do_notify(struct f_ncm *
data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
data[1] = data[0];

- DBG(cdev, "notify speed %d\n", ncm_bitrate(cdev->gadget));
+ DBG(cdev, "notify speed %u\n", ncm_bitrate(cdev->gadget));
ncm->notify_state = NCM_NOTIFY_CONNECT;
break;
}


2021-06-14 10:46:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 39/49] perf: Fix data race between pin_count increment/decrement

From: Marco Elver <[email protected]>

commit 6c605f8371159432ec61cbb1488dcf7ad24ad19a upstream.

KCSAN reports a data race between increment and decrement of pin_count:

write to 0xffff888237c2d4e0 of 4 bytes by task 15740 on cpu 1:
find_get_context kernel/events/core.c:4617
__do_sys_perf_event_open kernel/events/core.c:12097 [inline]
__se_sys_perf_event_open kernel/events/core.c:11933
...
read to 0xffff888237c2d4e0 of 4 bytes by task 15743 on cpu 0:
perf_unpin_context kernel/events/core.c:1525 [inline]
__do_sys_perf_event_open kernel/events/core.c:12328 [inline]
__se_sys_perf_event_open kernel/events/core.c:11933
...

Because neither read-modify-write here is atomic, this can lead to one
of the operations being lost, resulting in an inconsistent pin_count.
Fix it by adding the missing locking in the CPU-event case.

Fixes: fe4b04fa31a6 ("perf: Cure task_oncpu_function_call() races")
Reported-by: [email protected]
Signed-off-by: Marco Elver <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/events/core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3918,7 +3918,9 @@ find_get_context(struct pmu *pmu, struct
cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
ctx = &cpuctx->ctx;
get_ctx(ctx);
+ raw_spin_lock_irqsave(&ctx->lock, flags);
++ctx->pin_count;
+ raw_spin_unlock_irqrestore(&ctx->lock, flags);

return ctx;
}


2021-06-14 10:46:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 47/49] scsi: core: Only put parent device if host state differs from SHOST_CREATED

From: Ming Lei <[email protected]>

commit 1e0d4e6225996f05271de1ebcb1a7c9381af0b27 upstream.

get_device(shost->shost_gendev.parent) is called after host state has
switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the
parent device if host state is still SHOST_CREATED.

Link: https://lore.kernel.org/r/[email protected]
Cc: Bart Van Assche <[email protected]>
Cc: John Garry <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Tested-by: John Garry <[email protected]>
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/hosts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -355,7 +355,7 @@ static void scsi_host_dev_release(struct

ida_simple_remove(&host_index_ida, shost->host_no);

- if (parent)
+ if (shost->shost_state != SHOST_CREATED)
put_device(parent);
kfree(shost);
}


2021-06-14 10:46:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 46/49] scsi: core: Put .shost_dev in failure path if host state changes to RUNNING

From: Ming Lei <[email protected]>

commit 11714026c02d613c30a149c3f4c4a15047744529 upstream.

scsi_host_dev_release() only frees dev_name when host state is
SHOST_CREATED. After host state has changed to SHOST_RUNNING,
scsi_host_dev_release() no longer cleans up.

Fix this by doing a put_device(&shost->shost_dev) in the failure path when
host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before
device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put
on this reference.

Link: https://lore.kernel.org/r/[email protected]
Cc: Bart Van Assche <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Reported-by: John Garry <[email protected]>
Tested-by: John Garry <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/hosts.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -256,12 +256,11 @@ int scsi_add_host_with_dma(struct Scsi_H

device_enable_async_suspend(&shost->shost_dev);

+ get_device(&shost->shost_gendev);
error = device_add(&shost->shost_dev);
if (error)
goto out_del_gendev;

- get_device(&shost->shost_gendev);
-
if (shost->transportt->host_size) {
shost->shost_data = kzalloc(shost->transportt->host_size,
GFP_KERNEL);
@@ -298,6 +297,11 @@ int scsi_add_host_with_dma(struct Scsi_H
out_del_dev:
device_del(&shost->shost_dev);
out_del_gendev:
+ /*
+ * Host state is SHOST_RUNNING so we have to explicitly release
+ * ->shost_dev.
+ */
+ put_device(&shost->shost_dev);
device_del(&shost->shost_gendev);
out_disable_runtime_pm:
device_disable_async_suspend(&shost->shost_gendev);


2021-06-14 10:46:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 21/49] drm: Fix use-after-free read in drm_getunique()

From: Desmond Cheong Zhi Xi <[email protected]>

commit b436acd1cf7fac0ba987abd22955d98025c80c2b upstream.

There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.

An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.

To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test.

Reported-by: [email protected]
Signed-off-by: Desmond Cheong Zhi Xi <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/drm_ioctl.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -112,17 +112,18 @@ int drm_getunique(struct drm_device *dev
struct drm_file *file_priv)
{
struct drm_unique *u = data;
- struct drm_master *master = file_priv->master;
+ struct drm_master *master;

- mutex_lock(&master->dev->master_mutex);
+ mutex_lock(&dev->master_mutex);
+ master = file_priv->master;
if (u->unique_len >= master->unique_len) {
if (copy_to_user(u->unique, master->unique, master->unique_len)) {
- mutex_unlock(&master->dev->master_mutex);
+ mutex_unlock(&dev->master_mutex);
return -EFAULT;
}
}
u->unique_len = master->unique_len;
- mutex_unlock(&master->dev->master_mutex);
+ mutex_unlock(&dev->master_mutex);

return 0;
}


2021-06-14 10:46:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 41/49] perf session: Correct buffer copying when peeking events

From: Leo Yan <[email protected]>

[ Upstream commit 197eecb6ecae0b04bd694432f640ff75597fed9c ]

When peeking an event, it has a short path and a long path. The short
path uses the session pointer "one_mmap_addr" to directly fetch the
event; and the long path needs to read out the event header and the
following event data from file and fill into the buffer pointer passed
through the argument "buf".

The issue is in the long path that it copies the event header and event
data into the same destination address which pointer "buf", this means
the event header is overwritten. We are just lucky to run into the
short path in most cases, so we don't hit the issue in the long path.

This patch adds the offset "hdr_sz" to the pointer "buf" when copying
the event data, so that it can reserve the event header which can be
used properly by its caller.

Fixes: 5a52f33adf02 ("perf session: Add perf_session__peek_event()")
Signed-off-by: Leo Yan <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Kan Liang <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/perf/util/session.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index decd5d147e81..735dc862c7f8 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1475,6 +1475,7 @@ int perf_session__peek_event(struct perf_session *session, off_t file_offset,
if (event->header.size < hdr_sz || event->header.size > buf_sz)
return -1;

+ buf += hdr_sz;
rest = event->header.size - hdr_sz;

if (readn(fd, buf, rest) != (ssize_t)rest)
--
2.30.2



2021-06-14 10:49:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.14 18/49] powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers

From: Chris Packham <[email protected]>

[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]

The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.

Signed-off-by: Chris Packham <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index af12ead88c5f..404f570ebe23 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -122,7 +122,15 @@
};

/include/ "pq3-i2c-0.dtsi"
+ i2c@3000 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "pq3-i2c-1.dtsi"
+ i2c@3100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "pq3-duart-0.dtsi"
/include/ "pq3-espi-0.dtsi"
spi0: spi@7000 {
--
2.30.2



2021-06-15 02:25:14

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/49] 4.14.237-rc1 review



On 2021/6/14 18:26, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.237 release.
> There are 49 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 16 Jun 2021 10:26:30 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.237-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on x86 for 4.14.237-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.14.y
Version: 4.14.237-rc1
Commit: cd5358beb13452c589c392a4d3b91a7015a8c5cc
Compiler: gcc version 7.3.0 (GCC)

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8836
passed: 8836
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>

2021-06-15 09:54:22

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/49] 4.14.237-rc1 review

On Mon, 14 Jun 2021 at 16:03, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.14.237 release.
> There are 49 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 16 Jun 2021 10:26:30 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.237-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 4.14.237-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.14.y
* git commit: 2e03cf25d5d0197592eed1d477a1dca0ab898e16
* git describe: v4.14.236-50-g2e03cf25d5d0
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.236-50-g2e03cf25d5d0

## No regressions (compared to v4.14.236-40-gcd5358beb134)

## No fixes (compared to v4.14.236-40-gcd5358beb134)

## Test result summary
total: 60640, pass: 47894, fail: 1240, skip: 10366, xfail: 1140,

## Build Summary
* arm: 97 total, 97 passed, 0 failed
* arm64: 24 total, 24 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 14 total, 14 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 14 total, 14 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

2021-06-15 14:30:38

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/49] 4.14.237-rc1 review

On Mon, Jun 14, 2021 at 12:26:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.237 release.
> There are 49 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 16 Jun 2021 10:26:30 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 406 pass: 406 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter