Skip to contentSkip to conversation

4.9.55-stable review

PATCH In review Greg Kroah-Hartman 9 participants 121 messages Oct 10, 2017 – Oct 12, 2017

Subsystems (3)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.9.55-stable review

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 4.9.55-rc1

Paolo Bonzini <[email protected]>
KVM: x86: fix singlestepping over syscall

Jaegeuk Kim <[email protected]>
f2fs: don't allow encrypted operations without keys

Theodore Ts'o <[email protected]>
ext4: don't allow encrypted operations without keys

Jan Kara <[email protected]>
ext4: Don't clear SGID when inheriting ACLs

Jan Kara <[email protected]>
ext4: fix data corruption for mmap writes

Amir Goldstein <[email protected]>
vfs: deny copy_file_range() for non regular files

Peter Zijlstra <[email protected]>
sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs

Chanho Min <[email protected]>
mmc: core: add driver strength selection when selecting hs400es

Christoph Hellwig <[email protected]>
nvme-pci: Use PCI bus address for data/queues in CMB

Jani Nikula <[email protected]>
drm/i915/bios: ignore HDMI on port A

Arend Van Spriel <[email protected]>
brcmfmac: setup passive scan if requested by user-space

Arend Van Spriel <[email protected]>
brcmfmac: add length check in brcmf_cfg80211_escan_handler()

Martin K. Petersen <[email protected]>
scsi: sd: Do not override max_sectors_kb sysfs setting

Luca Coelho <[email protected]>
iwlwifi: add workaround to disable wide channels in 5GHz

Luca Coelho <[email protected]>
iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

Arnd Bergmann <[email protected]>

    netlink: fix nla_put_{u8,u16,u32} for KASAN

Arnd Bergmann <[email protected]>
rocker: fix rocker_tlv_put_* functions for KASAN

Ping Cheng <[email protected]>
HID: wacom: bits shifted too much for 9th and 10th buttons

Jason Gerecke <[email protected]>
HID: wacom: Always increment hdev refcount within wacom_get_hdev_data

Aaron Armstrong Skomra <[email protected]>
HID: wacom: leds: Don't try to control the EKR's read-only LEDs

Adrian Salido <[email protected]>
HID: i2c-hid: allocate hid buffers for real worst case

Shu Wang <[email protected]>
ftrace: Fix kmemleak in unregister_ftrace_graph

Alexander Shishkin <[email protected]>
stm class: Fix a use-after-free

Olaf Hering <[email protected]>
Drivers: hv: fcopy: restore correct transfer length

Nicolai Stange <[email protected]>
driver core: platform: Don't read past the end of "driver_override" buffer

Mark Rutland <[email protected]>
percpu: make this_cpu_generic_read() atomic w.r.t. interrupts

Gustavo Romero <[email protected]>
powerpc/tm: Fix illegal TM state in signal handler

Cyril Bur <[email protected]>
powerpc/64s: Use emergency stack for kernel TM Bad Thing program checks

Eric Dumazet <[email protected]>
socket, bpf: fix possible use after free

Nikolay Aleksandrov <[email protected]>
net: rtnetlink: fix info leak in RTM_GETSTATS call

Parthasarathy Bhuvaragan <[email protected]>
tipc: use only positive error codes in messages

Xin Long <[email protected]>
ip6_tunnel: update mtu properly for ARPHRD_ETHER tunnel device in tx path

Xin Long <[email protected]>
ip6_gre: ip6gre_tap device should keep dst

Jason A. Donenfeld <[email protected]>
netlink: do not proceed if dump's start() errs

Christoph Paasch <[email protected]>
net: Set sk_prot_creator when cloning sockets to the right proto

Willem de Bruijn <[email protected]>

    packet: only test po->has_vnet_hdr once in packet_snd

Willem de Bruijn <[email protected]>
packet: in packet_do_bind, test fanout with bind_lock held

Florian Fainelli <[email protected]>
net: dsa: Fix network device registration order

Alexander Potapenko <[email protected]>
tun: bail out from tun_get_user() if the skb is empty

Sabrina Dubroca <[email protected]>
l2tp: fix race condition in l2tp_tunnel_delete

Ridge Kennedy <[email protected]>
l2tp: Avoid schedule while atomic in exit_net

Alexey Kodanev <[email protected]>
vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit

Timur Tabi <[email protected]>
net: qcom/emac: specify the correct size when mapping a DMA buffer

Konstantin Khlebnikov <[email protected]>
net_sched: always reset qdisc backlog in qdisc_reset()

Meng Xu <[email protected]>
isdn/i4l: fetch the ppp_write buffer in one shot

Yonghong Song <[email protected]>
bpf: one perf event close won't free bpf program attached by another perf event

Willem de Bruijn <[email protected]>
packet: hold bind lock when rebinding to fanout hook

Christian Lamparter <[email protected]>
net: emac: Fix napi poll list corruption

Eric Dumazet <[email protected]>
tcp: fastopen: fix on syn-data transmit failure

Davide Caratti <[email protected]>
net/sched: cls_matchall: fix crash when used with classful qdisc

Xin Long <[email protected]>
ip6_tunnel: do not allow loading ip6_tunnel if ipv6 is disabled in cmdline

Fahad Kunnathadi <[email protected]>
net: phy: Fix mask value write on gmii2rgmii converter speed register

Xin Long <[email protected]>
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

Subash Abhinov Kasiviswanathan <[email protected]>
udpv6: Fix the checksum computation when HW checksum does not apply

Eric Dumazet <[email protected]>
tcp: fix data delivery rate

Edward Cree <[email protected]>
bpf/verifier: reject BPF_ALU64|BPF_END

Eric Dumazet <[email protected]>

    tcp: update skb->skb_mstamp more carefully

Dan Carpenter <[email protected]>
sctp: potential read out of bounds in sctp_ulpevent_type_enabled()

Jiri Pirko <[email protected]>
net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker

Yuval Mintz <[email protected]>
mlxsw: spectrum: Prevent mirred-related crash on removal

Takashi Iwai <[email protected]>
ALSA: usx2y: Suppress kernel warning at page allocation failures

Takashi Sakamoto <[email protected]>
Revert "ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members"

Guneshwor Singh <[email protected]>
ALSA: compress: Remove unused variable

Casey Schaufler <[email protected]>
lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

Sergey Senozhatsky <[email protected]>
lib/ratelimit.c: use deferred printk() version

Michal Hocko <[email protected]>
mm, oom_reaper: skip mm structs with mmu notifiers

Stefan Wahren <[email protected]>
staging: vchiq_2835_arm: Fix NULL ptr dereference in free_pagelist

Andrey Konovalov <[email protected]>
uwb: ensure that endpoint is interrupt

Andrey Konovalov <[email protected]>
uwb: properly check kthread_run return value

Lukas Wunner <[email protected]>

    iio: adc: mcp320x: Fix oops on module unload

Lukas Wunner <[email protected]>

    iio: adc: mcp320x: Fix readout of negative voltages

Dragos Bogdan <[email protected]>
iio: ad7793: Fix the serial interface reset

Colin Parker <[email protected]>
IIO: BME280: Updates to Humidity readings need ctrl_reg write!

Matt Fornero <[email protected]>
iio: core: Return error for failed read_reg

Stefan Popa <[email protected]>
staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.

Dragos Bogdan <[email protected]>
iio: ad_sigma_delta: Implement a dedicated reset function

Christophe JAILLET <[email protected]>
iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of 'twl4030_madc_probe()'

Christophe JAILLET <[email protected]>
iio: adc: twl4030: Fix an error handling path in 'twl4030_madc_probe()'

Kai-Heng Feng <[email protected]>
Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

Mathias Nyman <[email protected]>
xhci: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor

Mathias Nyman <[email protected]>
xhci: Fix sleeping with spin_lock_irq() held in ASmedia 1042A workaround

Mathias Nyman <[email protected]>
xhci: fix finding correct bus_state structure for USB 3.1 hosts

Greg Kroah-Hartman <[email protected]>
USB: fix out-of-bounds in usb_set_configuration

Dmitry Fleytman <[email protected]>
usb: Increase quirk delay for USB devices

Greg Kroah-Hartman <[email protected]>
USB: core: harden cdc_parse_cdc_header

Alan Stern <[email protected]>
USB: uas: fix bug in handling of alternate settings

Alan Stern <[email protected]>
USB: g_mass_storage: Fix deadlock when driver is unbound

Li Jun <[email protected]>
usb: gadget: mass_storage: set msg_registered after msg registered

Dan Carpenter <[email protected]>
USB: devio: Don't corrupt user memory

Alan Stern <[email protected]>
USB: dummy-hcd: Fix erroneous synchronization change

Alan Stern <[email protected]>
USB: dummy-hcd: fix infinite-loop resubmission bug

Alan Stern <[email protected]>
USB: dummy-hcd: fix connection failures (wrong speed)

Bjørn Mork <[email protected]>
USB: cdc-wdm: ignore -EPIPE from GetEncapsulatedResponse

Jim Dickerson <[email protected]>
usb: pci-quirks.c: Corrected timeout values used in handshake

Takashi Iwai <[email protected]>
ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor

Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

Alan Stern <[email protected]>
usb-storage: fix bogus hardware error messages for ATA pass-thru devices

Alan Stern <[email protected]>
usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

Yoshihiro Shimoda <[email protected]>
usb: gadget: udc: renesas_usb3: Fix return value of usb3_write_pipe()

Yoshihiro Shimoda <[email protected]>
usb: gadget: udc: renesas_usb3: fix Pn_RAMMAP.Pn_MPKT value

Yoshihiro Shimoda <[email protected]>
usb: gadget: udc: renesas_usb3: fix for no-data control transfer

Nicolas Ferre <[email protected]>
usb: gadget: udc: atmel: set vbus irqflags explicitly

Alan Stern <[email protected]>
USB: gadgetfs: fix copy_to_user while holding spinlock

Alan Stern <[email protected]>
USB: gadgetfs: Fix crash caused by inadequate synchronization

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

Diffstat:

 Makefile                                           |  4 +-
 arch/powerpc/kernel/exceptions-64s.S               | 24 ++++++-
 arch/powerpc/kernel/signal_64.c                    | 13 +++-
 arch/x86/include/asm/kvm_emulate.h                 |  1 +
 arch/x86/kvm/emulate.c                             |  1 +
 arch/x86/kvm/x86.c                                 | 52 +++++++--------
 drivers/base/platform.c                            |  3 +-
 drivers/gpu/drm/i915/intel_bios.c                  |  7 +++
 drivers/hid/i2c-hid/i2c-hid.c                      |  3 +-
 drivers/hid/wacom_sys.c                            |  7 ++-
 drivers/hid/wacom_wac.c                            |  4 +-
 drivers/hv/hv_fcopy.c                              |  4 ++
 drivers/hwtracing/stm/core.c                       |  2 +-
 drivers/iio/adc/ad7793.c                           |  4 +-
 drivers/iio/adc/ad_sigma_delta.c                   | 28 +++++++++
 drivers/iio/adc/mcp320x.c                          | 25 +++++---
 drivers/iio/adc/twl4030-madc.c                     | 10 ++-
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/iio/pressure/bmp280-core.c                 |  2 +-
 drivers/isdn/i4l/isdn_ppp.c                        | 37 +++++++----
 drivers/mmc/core/mmc.c                             | 36 ++++++-----
 drivers/net/ethernet/ibm/emac/mal.c                |  3 +-
 drivers/net/ethernet/mellanox/mlxsw/spectrum.c     | 20 +++---
 drivers/net/ethernet/qualcomm/emac/emac-mac.c      |  3 +-
 drivers/net/ethernet/rocker/rocker_tlv.h           | 48 ++++++++------
 drivers/net/phy/xilinx_gmii2rgmii.c                |  2 +-
 drivers/net/tun.c                                  |  8 ++-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         | 37 +++++------
 .../broadcom/brcm80211/brcmfmac/fwil_types.h       |  5 ++
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 66 +++++++++++++++----
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 10 ++-
 drivers/nvme/host/pci.c                            | 14 ++---
 drivers/scsi/sd.c                                  | 19 ++++--
 drivers/staging/iio/adc/ad7192.c                   |  4 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c           |  6 +-
 drivers/usb/class/cdc-wdm.c                        |  4 +-
 drivers/usb/core/config.c                          | 16 +++--
 drivers/usb/core/devio.c                           |  6 +-
 drivers/usb/core/hub.c                             |  2 +-
 drivers/usb/core/message.c                         |  4 ++
 drivers/usb/gadget/function/f_mass_storage.c       | 27 +++-----
 drivers/usb/gadget/function/f_mass_storage.h       | 14 -----
 drivers/usb/gadget/legacy/inode.c                  | 46 ++++++++++++--
 drivers/usb/gadget/legacy/mass_storage.c           | 20 +-----
 drivers/usb/gadget/udc/atmel_usba_udc.c            |  4 +-
 drivers/usb/gadget/udc/dummy_hcd.c                 | 56 +++++++++++++++--
 drivers/usb/gadget/udc/renesas_usb3.c              | 19 ++++--
 drivers/usb/host/pci-quirks.c                      | 10 +--
 drivers/usb/host/xhci-hub.c                        | 14 +++--
 drivers/usb/host/xhci-pci.c                        | 12 ----
 drivers/usb/host/xhci.h                            |  4 +-
 drivers/usb/renesas_usbhs/fifo.c                   | 21 ++++++-
 drivers/usb/storage/transport.c                    | 14 ++++-
 drivers/usb/storage/uas-detect.h                   | 15 ++---
 drivers/usb/storage/uas.c                          | 10 +--
 drivers/usb/storage/unusual_devs.h                 |  7 +++
 drivers/uwb/hwa-rc.c                               |  2 +
 drivers/uwb/uwbd.c                                 | 12 ++--
 fs/ext4/acl.c                                      | 22 ++++---
 fs/ext4/inode.c                                    | 18 +++++-
 fs/ext4/namei.c                                    | 12 ++++
 fs/f2fs/namei.c                                    | 12 ++++
 fs/read_write.c                                    |  5 ++
 fs/xattr.c                                         |  2 +-
 include/asm-generic/percpu.h                       | 24 ++++++-
 include/linux/cpuset.h                             |  6 ++
 include/linux/iio/adc/ad_sigma_delta.h             |  3 +
 include/linux/mmu_notifier.h                       |  5 ++
 include/linux/trace_events.h                       |  1 +
 include/net/netlink.h                              | 73 ++++++++++++++++------
 include/net/sctp/ulpevent.h                        |  6 +-
 include/uapi/linux/usb/ch9.h                       |  1 +
 kernel/bpf/verifier.c                              |  3 +-
 kernel/cpuset.c                                    | 16 ++++-
 kernel/events/core.c                               |  3 +-
 kernel/power/process.c                             |  5 +-
 kernel/sched/core.c                                |  7 +--
 kernel/trace/ftrace.c                              | 14 -----
 lib/ratelimit.c                                    |  4 +-
 mm/oom_kill.c                                      | 16 +++++
 net/core/filter.c                                  | 15 ++++-
 net/core/rtnetlink.c                               |  3 +
 net/core/sock.c                                    |  7 ++-
 net/dsa/slave.c                                    | 28 +++++----
 net/ipv4/ip_vti.c                                  |  3 +-
 net/ipv4/tcp_output.c                              | 33 +++++++---
 net/ipv6/ip6_gre.c                                 | 22 ++++---
 net/ipv6/ip6_tunnel.c                              |  8 ++-
 net/ipv6/ip6_vti.c                                 |  3 +-
 net/ipv6/udp.c                                     |  1 +
 net/l2tp/l2tp_core.c                               | 14 ++---
 net/l2tp/l2tp_core.h                               |  5 +-
 net/netlink/af_netlink.c                           |  7 ++-
 net/packet/af_packet.c                             | 28 ++++++---
 net/sched/act_api.c                                |  6 +-
 net/sched/cls_matchall.c                           |  1 +
 net/sched/sch_generic.c                            |  1 +
 net/tipc/msg.c                                     |  2 +-
 security/smack/smack_lsm.c                         | 55 ++++++++--------
 sound/core/compress_offload.c                      |  3 +-
 sound/pci/echoaudio/echoaudio.c                    |  6 +-
 sound/usb/card.c                                   | 20 ++++++
 sound/usb/usx2y/usb_stream.c                       |  6 +-
 103 files changed, 953 insertions(+), 437 deletions(-)
author maintainer
#1 lore raw

PATCH 1/105 USB: gadgetfs: Fix crash caused by inadequate synchronization

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 520b72fc64debf8a86c3853b8e486aa5982188f0 upstream.

The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written before the UDC and composite frameworks were adopted; it is a legacy driver. As such, it expects that once bound to a UDC controller, it will not be unbound until it unregisters itself.

However, the UDC framework does unbind function drivers while they are still registered. When this happens, it can cause the gadgetfs driver to misbehave or crash. For example, userspace can cause a crash by opening the device file and doing an ioctl call before setting up a configuration (found by Andrey Konovalov using the syzkaller fuzzer).

This patch adds checks and synchronization to prevent these bad behaviors. It adds a udc_usage counter that the driver increments at times when it is using a gadget interface without holding the private spinlock. The unbind routine waits for this counter to go to 0 before returning, thereby ensuring that the UDC is no longer in use.

The patch also adds a check in the dev_ioctl() routine to make sure the driver is bound to a UDC before dereferencing the gadget pointer, and it makes destroy_ep_files() synchronize with the endpoint I/O routines, to prevent the user from accessing an endpoint data structure after it has been removed.

---
 drivers/usb/gadget/legacy/inode.c |   41 +++++++++++++++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 5 deletions(-)
drivers/usb/gadget/legacy/inode.c +36 -5
@@ -27,7 +27,7 @@
 #include <linux/mmu_context.h>
 #include <linux/aio.h>
 #include <linux/uio.h>
-
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/moduleparam.h>
 
@@ -116,6 +116,7 @@ enum ep0_state {
 struct dev_data {
 	spinlock_t			lock;
 	atomic_t			count;
+	int				udc_usage;
 	enum ep0_state			state;		/* P: lock */
 	struct usb_gadgetfs_event	event [N_EVENT];
 	unsigned			ev_next;
@@ -513,9 +514,9 @@ static void ep_aio_complete(struct usb_e
 		INIT_WORK(&priv->work, ep_user_copy_worker);
 		schedule_work(&priv->work);
 	}
-	spin_unlock(&epdata->dev->lock);
 
 	usb_ep_free_request(ep, req);
+	spin_unlock(&epdata->dev->lock);
 	put_ep(epdata);
 }
 
@@ -939,9 +940,11 @@ ep0_read (struct file *fd, char __user *
 			struct usb_request	*req = dev->req;
 
 			if ((retval = setup_req (ep, req, 0)) == 0) {
+				++dev->udc_usage;
 				spin_unlock_irq (&dev->lock);
 				retval = usb_ep_queue (ep, req, GFP_KERNEL);
 				spin_lock_irq (&dev->lock);
+				--dev->udc_usage;
 			}
 			dev->state = STATE_DEV_CONNECTED;
 
@@ -1131,6 +1134,7 @@ ep0_write (struct file *fd, const char _
 			retval = setup_req (dev->gadget->ep0, dev->req, len);
 			if (retval == 0) {
 				dev->state = STATE_DEV_CONNECTED;
+				++dev->udc_usage;
 				spin_unlock_irq (&dev->lock);
 				if (copy_from_user (dev->req->buf, buf, len))
 					retval = -EFAULT;
@@ -1142,6 +1146,7 @@ ep0_write (struct file *fd, const char _
 						GFP_KERNEL);
 				}
 				spin_lock_irq(&dev->lock);
+				--dev->udc_usage;
 				if (retval < 0) {
 					clean_req (dev->gadget->ep0, dev->req);
 				} else
@@ -1243,9 +1248,21 @@ static long dev_ioctl (struct file *fd,
 	struct usb_gadget	*gadget = dev->gadget;
 	long ret = -ENOTTY;
 
-	if (gadget->ops->ioctl)
+	spin_lock_irq(&dev->lock);
+	if (dev->state == STATE_DEV_OPENED ||
+			dev->state == STATE_DEV_UNBOUND) {
+		/* Not bound to a UDC */
+	} else if (gadget->ops->ioctl) {
+		++dev->udc_usage;
+		spin_unlock_irq(&dev->lock);
+
 		ret = gadget->ops->ioctl (gadget, code, value);
 
+		spin_lock_irq(&dev->lock);
+		--dev->udc_usage;
+	}
+	spin_unlock_irq(&dev->lock);
+
 	return ret;
 }
 
@@ -1463,10 +1480,12 @@ delegate:
 				if (value < 0)
 					break;
 
+				++dev->udc_usage;
 				spin_unlock (&dev->lock);
 				value = usb_ep_queue (gadget->ep0, dev->req,
 							GFP_KERNEL);
 				spin_lock (&dev->lock);
+				--dev->udc_usage;
 				if (value < 0) {
 					clean_req (gadget->ep0, dev->req);
 					break;
@@ -1490,8 +1509,12 @@ delegate:
 		req->length = value;
 		req->zero = value < w_length;
 
+		++dev->udc_usage;
 		spin_unlock (&dev->lock);
 		value = usb_ep_queue (gadget->ep0, req, GFP_KERNEL);
+		spin_lock(&dev->lock);
+		--dev->udc_usage;
+		spin_unlock(&dev->lock);
 		if (value < 0) {
 			DBG (dev, "ep_queue --> %d\n", value);
 			req->status = 0;
@@ -1518,21 +1541,24 @@ static void destroy_ep_files (struct dev
 		/* break link to FS */
 		ep = list_first_entry (&dev->epfiles, struct ep_data, epfiles);
 		list_del_init (&ep->epfiles);
+		spin_unlock_irq (&dev->lock);
+
 		dentry = ep->dentry;
 		ep->dentry = NULL;
 		parent = d_inode(dentry->d_parent);
 
 		/* break link to controller */
+		mutex_lock(&ep->lock);
 		if (ep->state == STATE_EP_ENABLED)
 			(void) usb_ep_disable (ep->ep);
 		ep->state = STATE_EP_UNBOUND;
 		usb_ep_free_request (ep->ep, ep->req);
 		ep->ep = NULL;
+		mutex_unlock(&ep->lock);
+
 		wake_up (&ep->wait);
 		put_ep (ep);
 
-		spin_unlock_irq (&dev->lock);
-
 		/* break link to dcache */
 		inode_lock(parent);
 		d_delete (dentry);
@@ -1603,6 +1629,11 @@ gadgetfs_unbind (struct usb_gadget *gadg
 
 	spin_lock_irq (&dev->lock);
 	dev->state = STATE_DEV_UNBOUND;
+	while (dev->udc_usage > 0) {
+		spin_unlock_irq(&dev->lock);
+		usleep_range(1000, 2000);
+		spin_lock_irq(&dev->lock);
+	}
 	spin_unlock_irq (&dev->lock);
 
 	destroy_ep_files (dev);
author maintainer
#2 lore raw

PATCH 2/105 USB: gadgetfs: fix copy_to_user while holding spinlock

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 6e76c01e71551cb221c1f3deacb9dcd9a7346784 upstream.

The gadgetfs driver as a long-outstanding FIXME, regarding a call of copy_to_user() made while holding a spinlock. This patch fixes the issue by dropping the spinlock and using the dev->udc_usage mechanism introduced by another recent patch to guard against status changes while the lock isn't held.

---
 drivers/usb/gadget/legacy/inode.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/usb/gadget/legacy/inode.c +4 -1
@@ -986,11 +986,14 @@ ep0_read (struct file *fd, char __user *
 				retval = -EIO;
 			else {
 				len = min (len, (size_t)dev->req->actual);
-// FIXME don't call this with the spinlock held ...
+				++dev->udc_usage;
+				spin_unlock_irq(&dev->lock);
 				if (copy_to_user (buf, dev->req->buf, len))
 					retval = -EFAULT;
 				else
 					retval = len;
+				spin_lock_irq(&dev->lock);
+				--dev->udc_usage;
 				clean_req (dev->gadget->ep0, dev->req);
 				/* NOTE userspace can't yet choose to stall */
 			}
author maintainer
#3 lore raw

PATCH 3/105 usb: gadget: udc: atmel: set vbus irqflags explicitly

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Ferre <[email protected]>

commit 6baeda120d90aa637b08f7604de104ab00ce9126 upstream.

The driver triggers actions on both edges of the vbus signal.

The former PIO controller was triggering IRQs on both falling and rising edges by default. Newer PIO controller don't, so it's better to set it explicitly to IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.

Without this patch we may trigger the connection with host but only on some bouncing signal conditions and thus lose connecting events.

---
 drivers/usb/gadget/udc/atmel_usba_udc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/gadget/udc/atmel_usba_udc.c +3 -1
@@ -28,6 +28,8 @@
 #include <linux/of_gpio.h>
 
 #include "atmel_usba_udc.h"
+#define USBA_VBUS_IRQFLAGS (IRQF_ONESHOT \
+			   | IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING)
 
 #ifdef CONFIG_USB_GADGET_DEBUG_FS
 #include <linux/debugfs.h>
@@ -2172,7 +2174,7 @@ static int usba_udc_probe(struct platfor
 					IRQ_NOAUTOEN);
 			ret = devm_request_threaded_irq(&pdev->dev,
 					gpio_to_irq(udc->vbus_pin), NULL,
-					usba_vbus_irq_thread, IRQF_ONESHOT,
+					usba_vbus_irq_thread, USBA_VBUS_IRQFLAGS,
 					"atmel_usba_udc", udc);
 			if (ret) {
 				udc->vbus_pin = -ENODEV;
author maintainer
#4 lore raw

PATCH 4/105 usb: gadget: udc: renesas_usb3: fix for no-data control transfer

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

commit 4dcf4bab4a409e81284b8202137e4a85b96b34de upstream.

When bRequestType & USB_DIR_IN is false and req.length is 0 in control transfer, since it means non-data, this driver should not set the mode as control write. So, this patch fixes it.

Fixes 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
---
 drivers/usb/gadget/udc/renesas_usb3.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/gadget/udc/renesas_usb3.c +2 -1
@@ -991,7 +991,8 @@ static void usb3_start_pipe0(struct rene
 		usb3_set_p0_con_for_ctrl_read_data(usb3);
 	} else {
 		usb3_clear_bit(usb3, P0_MOD_DIR, USB3_P0_MOD);
-		usb3_set_p0_con_for_ctrl_write_data(usb3);
+		if (usb3_req->req.length)
+			usb3_set_p0_con_for_ctrl_write_data(usb3);
 	}
 
 	usb3_p0_xfer(usb3_ep, usb3_req);
author maintainer
#5 lore raw

PATCH 5/105 usb: gadget: udc: renesas_usb3: fix Pn_RAMMAP.Pn_MPKT value

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

commit 73f2f5745f18b4ccfe9484deac4e84a1378d19fd upstream.

According to the datasheet of R-Car Gen3, the Pn_RAMMAP.Pn_MPKT should be set to one of 8, 16, 32, 64, 512 and 1024. Otherwise, when a gadget driver uses an interrupt endpoint, unexpected behavior happens. So, this patch fixes it.

Fixes 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
---
 drivers/usb/gadget/udc/renesas_usb3.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/usb/gadget/udc/renesas_usb3.c +10 -1
@@ -1569,7 +1569,16 @@ static u32 usb3_calc_ramarea(int ram_siz
 static u32 usb3_calc_rammap_val(struct renesas_usb3_ep *usb3_ep,
 				const struct usb_endpoint_descriptor *desc)
 {
-	return usb3_ep->rammap_val | PN_RAMMAP_MPKT(usb_endpoint_maxp(desc));
+	int i;
+	const u32 max_packet_array[] = {8, 16, 32, 64, 512};
+	u32 mpkt = PN_RAMMAP_MPKT(1024);
+
+	for (i = 0; i < ARRAY_SIZE(max_packet_array); i++) {
+		if (usb_endpoint_maxp(desc) <= max_packet_array[i])
+			mpkt = PN_RAMMAP_MPKT(max_packet_array[i]);
+	}
+
+	return usb3_ep->rammap_val | mpkt;
 }
 
 static int usb3_enable_pipe_n(struct renesas_usb3_ep *usb3_ep,
author maintainer
#6 lore raw

PATCH 6/105 usb: gadget: udc: renesas_usb3: Fix return value of usb3_write_pipe()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

commit 447b8a01b84f048d93d43bfe1fcaa4fcc56595cc upstream.

This patch fixes an issue that this driver cannot go status stage in control read when the req.zero is set to 1 and the len in usb3_write_pipe() is set to 0. Otherwise, if we use g_ncm driver, usb enumeration takes long time (5 seconds or more).

Fixes 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
---
 drivers/usb/gadget/udc/renesas_usb3.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/gadget/udc/renesas_usb3.c +3 -2
@@ -879,7 +879,7 @@ static int usb3_write_pipe(struct renesa
 			usb3_ep->ep.maxpacket);
 	u8 *buf = usb3_req->req.buf + usb3_req->req.actual;
 	u32 tmp = 0;
-	bool is_last;
+	bool is_last = !len ? true : false;
 
 	if (usb3_wait_pipe_status(usb3_ep, PX_STA_BUFSTS) < 0)
 		return -EBUSY;
@@ -900,7 +900,8 @@ static int usb3_write_pipe(struct renesa
 		usb3_write(usb3, tmp, fifo_reg);
 	}
 
-	is_last = usb3_is_transfer_complete(usb3_ep, usb3_req);
+	if (!is_last)
+		is_last = usb3_is_transfer_complete(usb3_ep, usb3_req);
 	/* Send the data */
 	usb3_set_px_con_send(usb3_ep, len, is_last);
 
author maintainer
#7 lore raw

PATCH 7/105 usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 113f6eb6d50cfa5e2a1cdcf1678b12661fa272ab upstream.

Kris Lindgren reports that without the NO_WP_DETECT flag, his Seagate external disk drive fails all write accesses. This regresssion dates back approximately to the start of the 4.x kernel releases.

---
 drivers/usb/storage/unusual_devs.h |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/usb/storage/unusual_devs.h +7 -0
@@ -1459,6 +1459,13 @@ UNUSUAL_DEV( 0x0bc2, 0x3010, 0x0000, 0x0
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_SANE_SENSE ),
 
+/* Reported by Kris Lindgren <[email protected]> */
+UNUSUAL_DEV( 0x0bc2, 0x3332, 0x0000, 0x9999,
+		"Seagate",
+		"External",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_WP_DETECT ),
+
 UNUSUAL_DEV(  0x0d49, 0x7310, 0x0000, 0x9999,
 		"Maxtor",
 		"USB to SATA",
author maintainer
#8 lore raw

PATCH 8/105 usb-storage: fix bogus hardware error messages for ATA pass-thru devices

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit a4fd4a724d6c30ad671046d83be2e9be2f11d275 upstream.

Ever since commit a621bac3044e ("scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands"), people have been getting bogus error messages for USB disk drives using ATA pass-thru. For example:

[ 1344.880193] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 1345.069152] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[ 1345.069159] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor]
[ 1345.069162] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information
[ 1345.069168] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
[ 1345.172252] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[ 1345.172258] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor]
[ 1345.172261] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information
[ 1345.172266] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00

These messages can be quite annoying, because programs like udisks2 provoke them every 10 minutes or so. Other programs can also have this effect, such as those in smartmontools.

I don't fully understand how that commit induced the SCSI core to log these error messages, but the underlying cause for them is code added to usb-storage by commit f1a0743bc0e7 ("USB: storage: When a device returns no sense data, call it a Hardware Error"). At the time it was necessary to do this, in order to prevent an infinite retry loop with some not-so-great mass storage devices.

However, the ATA pass-thru protocol uses SCSI sense data to return command status values, and some devices always report Check Condition status for ATA pass-thru commands to ensure that the host retrieves the sense data, even if the command succeeded. This violates the USB mass-storage protocol (Check Condition status is supposed to mean the command failed), but we can't help that.

This patch attempts to mitigate the problem of these bogus error reports by changing usb-storage. The HARDWARE ERROR sense key will be inserted only for commands that aren't ATA pass-thru.

Thanks to Ewan Milne for pointing out that this mechanism was present in usb-storage. 8 years after writing it, I had completely forgotten its existence.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1351305

---
 drivers/usb/storage/transport.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
drivers/usb/storage/transport.c +13 -1
@@ -834,13 +834,25 @@ Retry_Sense:
 			if (result == USB_STOR_TRANSPORT_GOOD) {
 				srb->result = SAM_STAT_GOOD;
 				srb->sense_buffer[0] = 0x0;
+			}
+
+			/*
+			 * ATA-passthru commands use sense data to report
+			 * the command completion status, and often devices
+			 * return Check Condition status when nothing is
+			 * wrong.
+			 */
+			else if (srb->cmnd[0] == ATA_16 ||
+					srb->cmnd[0] == ATA_12) {
+				/* leave the data alone */
+			}
 
 			/*
 			 * If there was a problem, report an unspecified
 			 * hardware error to prevent the higher layers from
 			 * entering an infinite retry loop.
 			 */
-			} else {
+			else {
 				srb->result = DID_ERROR << 16;
 				if ((sshdr.response_code & 0x72) == 0x72)
 					srb->sense_buffer[1] = HARDWARE_ERROR;
author maintainer
#9 lore raw

PATCH 9/105 usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

commit 6124607acc88fffeaadf3aacfeb3cc1304c87387 upstream.

This patch fixes an issue that the driver sets the BCLR bit of {C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and the FRDY bit of {C,Dn}FIFOCTR register is set to 1.

Fixes e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
---
 drivers/usb/renesas_usbhs/fifo.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/usb/renesas_usbhs/fifo.c +8 -2
@@ -285,11 +285,17 @@ static void usbhsf_fifo_clear(struct usb
 			      struct usbhs_fifo *fifo)
 {
 	struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+	int ret = 0;
 
 	if (!usbhs_pipe_is_dcp(pipe))
-		usbhsf_fifo_barrier(priv, fifo);
+		ret = usbhsf_fifo_barrier(priv, fifo);
 
-	usbhs_write(priv, fifo->ctr, BCLR);
+	/*
+	 * if non-DCP pipe, this driver should set BCLR when
+	 * usbhsf_fifo_barrier() returns 0.
+	 */
+	if (!ret)
+		usbhs_write(priv, fifo->ctr, BCLR);
 }
 
 static int usbhsf_fifo_rcv_len(struct usbhs_priv *priv,
author maintainer
#10 lore raw

PATCH 10/105 usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

commit 0a2ce62b61f2c76d0213edf4e37aaf54a8ddf295 upstream.

This patch fixes an issue that the usbhsf_fifo_clear() is possible to cause 10 msec delay if the pipe is RX direction and empty because the FRDY bit will never be set to 1 in such case.

Fixes e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
---
 drivers/usb/renesas_usbhs/fifo.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/usb/renesas_usbhs/fifo.c +11 -2
@@ -287,8 +287,17 @@ static void usbhsf_fifo_clear(struct usb
 	struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
 	int ret = 0;
 
-	if (!usbhs_pipe_is_dcp(pipe))
-		ret = usbhsf_fifo_barrier(priv, fifo);
+	if (!usbhs_pipe_is_dcp(pipe)) {
+		/*
+		 * This driver checks the pipe condition first to avoid -EBUSY
+		 * from usbhsf_fifo_barrier() with about 10 msec delay in
+		 * the interrupt handler if the pipe is RX direction and empty.
+		 */
+		if (usbhs_pipe_is_dir_in(pipe))
+			ret = usbhs_pipe_is_accessible(pipe);
+		if (!ret)
+			ret = usbhsf_fifo_barrier(priv, fifo);
+	}
 
 	/*
 	 * if non-DCP pipe, this driver should set BCLR when
author maintainer
#11 lore raw

PATCH 11/105 ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Takashi Iwai <[email protected]>

commit bfc81a8bc18e3c4ba0cbaa7666ff76be2f998991 upstream.

When a USB-audio device receives a maliciously adjusted or corrupted buffer descriptor, the USB-audio driver may access an out-of-bounce value at its parser. This was detected by syzkaller, something like:

  BUG: KASAN: slab-out-of-bounds in usb_audio_probe+0x27b2/0x2ab0
  Read of size 1 at addr ffff88006b83a9e8 by task kworker/0:1/24
  CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #224
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Workqueue: usb_hub_wq hub_event
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x292/0x395 lib/dump_stack.c:52
   print_address_description+0x78/0x280 mm/kasan/report.c:252
   kasan_report_error mm/kasan/report.c:351
   kasan_report+0x22f/0x340 mm/kasan/report.c:409
   __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
   snd_usb_create_streams sound/usb/card.c:248
   usb_audio_probe+0x27b2/0x2ab0 sound/usb/card.c:605
   usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
   generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
   usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
   hub_port_connect drivers/usb/core/hub.c:4903
   hub_port_connect_change drivers/usb/core/hub.c:5009
   port_event drivers/usb/core/hub.c:5115
   hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
   process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
   worker_thread+0x221/0x1850 kernel/workqueue.c:2253
   kthread+0x3a1/0x470 kernel/kthread.c:231
   ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

This patch adds the checks of out-of-bounce accesses at appropriate places and bails out when it goes out of the given buffer.

---
 sound/usb/card.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
sound/usb/card.c +20 -0
@@ -221,6 +221,7 @@ static int snd_usb_create_streams(struct
 	struct usb_interface_descriptor *altsd;
 	void *control_header;
 	int i, protocol;
+	int rest_bytes;
 
 	/* find audiocontrol interface */
 	host_iface = &usb_ifnum_to_if(dev, ctrlif)->altsetting[0];
@@ -235,6 +236,15 @@ static int snd_usb_create_streams(struct
 		return -EINVAL;
 	}
 
+	rest_bytes = (void *)(host_iface->extra + host_iface->extralen) -
+		control_header;
+
+	/* just to be sure -- this shouldn't hit at all */
+	if (rest_bytes <= 0) {
+		dev_err(&dev->dev, "invalid control header\n");
+		return -EINVAL;
+	}
+
 	switch (protocol) {
 	default:
 		dev_warn(&dev->dev,
@@ -245,11 +255,21 @@ static int snd_usb_create_streams(struct
 	case UAC_VERSION_1: {
 		struct uac1_ac_header_descriptor *h1 = control_header;
 
+		if (rest_bytes < sizeof(*h1)) {
+			dev_err(&dev->dev, "too short v1 buffer descriptor\n");
+			return -EINVAL;
+		}
+
 		if (!h1->bInCollection) {
 			dev_info(&dev->dev, "skipping empty audio interface (v1)\n");
 			return -EINVAL;
 		}
 
+		if (rest_bytes < h1->bLength) {
+			dev_err(&dev->dev, "invalid buffer length (v1)\n");
+			return -EINVAL;
+		}
+
 		if (h1->bLength < sizeof(*h1) + h1->bInCollection) {
 			dev_err(&dev->dev, "invalid UAC_HEADER (v1)\n");
 			return -EINVAL;
author maintainer
#12 lore raw

PATCH 12/105 usb: pci-quirks.c: Corrected timeout values used in handshake

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jim Dickerson <[email protected]>

commit 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not waiting the full 1 second as designated in section 4.22.1 of the eXtensible Host Controller Interface specifications. The handshake was using wrong units so calls were made with milliseconds not microseconds. Comments referenced 5 seconds not 1 second as in specs.

The wrong units were also corrected in a second handshake call.

---
 drivers/usb/host/pci-quirks.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/host/pci-quirks.c +4 -4
@@ -1022,7 +1022,7 @@ EXPORT_SYMBOL_GPL(usb_disable_xhci_ports
  *
  * Takes care of the handoff between the Pre-OS (i.e. BIOS) and the OS.
  * It signals to the BIOS that the OS wants control of the host controller,
- * and then waits 5 seconds for the BIOS to hand over control.
+ * and then waits 1 second for the BIOS to hand over control.
  * If we timeout, assume the BIOS is broken and take control anyway.
  */
 static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
@@ -1069,9 +1069,9 @@ static void quirk_usb_handoff_xhci(struc
 	if (val & XHCI_HC_BIOS_OWNED) {
 		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
-		/* Wait for 5 seconds with 10 microsecond polling interval */
+		/* Wait for 1 second with 10 microsecond polling interval */
 		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
-				0, 5000, 10);
+				0, 1000000, 10);
 
 		/* Assume a buggy BIOS and take HC ownership anyway */
 		if (timeout) {
@@ -1100,7 +1100,7 @@ hc_init:
 	 * operational or runtime registers.  Wait 5 seconds and no more.
 	 */
 	timeout = handshake(op_reg_base + XHCI_STS_OFFSET, XHCI_STS_CNR, 0,
-			5000, 10);
+			5000000, 10);
 	/* Assume a buggy HC and start HC initialization anyway */
 	if (timeout) {
 		val = readl(op_reg_base + XHCI_STS_OFFSET);
author maintainer
#13 lore raw

PATCH 14/105 USB: dummy-hcd: fix connection failures (wrong speed)

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit fe659bcc9b173bcfdd958ce2aec75e47651e74e1 upstream.

The dummy-hcd UDC driver is not careful about the way it handles connection speeds. It ignores the module parameter that is supposed to govern the maximum connection speed and it doesn't set the HCD flags properly for the case where it ends up running at full speed.

The result is that in many cases, gadget enumeration over dummy-hcd fails because the bMaxPacketSize byte in the device descriptor is set incorrectly. For example, the default settings call for a high-speed connection, but the maxpacket value for ep0 ends up being set for a Super-Speed connection.

This patch fixes the problem by initializing the gadget's max_speed and the HCD flags correctly.

---
 drivers/usb/gadget/udc/dummy_hcd.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +11 -4
@@ -1030,7 +1030,12 @@ static int dummy_udc_probe(struct platfo
 	memzero_explicit(&dum->gadget, sizeof(struct usb_gadget));
 	dum->gadget.name = gadget_name;
 	dum->gadget.ops = &dummy_ops;
-	dum->gadget.max_speed = USB_SPEED_SUPER;
+	if (mod_data.is_super_speed)
+		dum->gadget.max_speed = USB_SPEED_SUPER;
+	else if (mod_data.is_high_speed)
+		dum->gadget.max_speed = USB_SPEED_HIGH;
+	else
+		dum->gadget.max_speed = USB_SPEED_FULL;
 
 	dum->gadget.dev.parent = &pdev->dev;
 	init_dummy_udc_hw(dum);
@@ -2559,8 +2564,6 @@ static struct hc_driver dummy_hcd = {
 	.product_desc =		"Dummy host controller",
 	.hcd_priv_size =	sizeof(struct dummy_hcd),
 
-	.flags =		HCD_USB3 | HCD_SHARED,
-
 	.reset =		dummy_setup,
 	.start =		dummy_start,
 	.stop =			dummy_stop,
@@ -2589,8 +2592,12 @@ static int dummy_hcd_probe(struct platfo
 	dev_info(&pdev->dev, "%s, driver " DRIVER_VERSION "\n", driver_desc);
 	dum = *((void **)dev_get_platdata(&pdev->dev));
 
-	if (!mod_data.is_super_speed)
+	if (mod_data.is_super_speed)
+		dummy_hcd.flags = HCD_USB3 | HCD_SHARED;
+	else if (mod_data.is_high_speed)
 		dummy_hcd.flags = HCD_USB2;
+	else
+		dummy_hcd.flags = HCD_USB11;
 	hs_hcd = usb_create_hcd(&dummy_hcd, &pdev->dev, dev_name(&pdev->dev));
 	if (!hs_hcd)
 		return -ENOMEM;
author maintainer
#14 lore raw

PATCH 15/105 USB: dummy-hcd: fix infinite-loop resubmission bug

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 0173a68bfb0ad1c72a6ee39cc485aa2c97540b98 upstream.

The dummy-hcd HCD/UDC emulator tries not to do too much work during each timer interrupt. But it doesn't try very hard; currently all it does is limit the total amount of bulk data transferred. Other transfer types aren't limited, and URBs that transfer no data (because of an error, perhaps) don't count toward the limit, even though on a real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop, for example, if the host class driver resubmits an URB every time it completes (which is common for interrupt URBs). Each time the URB is resubmitted it gets added to the end of the pending-URBs list, and dummy-hcd doesn't stop until that list is empty. Andrey Konovalov was able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs handled during each timer interrupt to those that were already on the pending list when the interrupt routine started. Newly added URBs won't be processed until the next timer interrupt. The problem of properly accounting for non-bulk bandwidth (as well as packet and transaction overhead) is not addressed here.

---
 drivers/usb/gadget/udc/dummy_hcd.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/usb/gadget/udc/dummy_hcd.c +9 -0
@@ -237,6 +237,8 @@ struct dummy_hcd {
 
 	struct usb_device		*udev;
 	struct list_head		urbp_list;
+	struct urbp			*next_frame_urbp;
+
 	u32				stream_en_ep;
 	u8				num_stream[30 / 2];
 
@@ -1244,6 +1246,8 @@ static int dummy_urb_enqueue(
 
 	list_add_tail(&urbp->urbp_list, &dum_hcd->urbp_list);
 	urb->hcpriv = urbp;
+	if (!dum_hcd->next_frame_urbp)
+		dum_hcd->next_frame_urbp = urbp;
 	if (usb_pipetype(urb->pipe) == PIPE_CONTROL)
 		urb->error_count = 1;		/* mark as a new urb */
 
@@ -1761,6 +1765,7 @@ static void dummy_timer(unsigned long _d
 		spin_unlock_irqrestore(&dum->lock, flags);
 		return;
 	}
+	dum_hcd->next_frame_urbp = NULL;
 
 	for (i = 0; i < DUMMY_ENDPOINTS; i++) {
 		if (!ep_info[i].name)
@@ -1777,6 +1782,10 @@ restart:
 		int			type;
 		int			status = -EINPROGRESS;
 
+		/* stop when we reach URBs queued after the timer interrupt */
+		if (urbp == dum_hcd->next_frame_urbp)
+			break;
+
 		urb = urbp->urb;
 		if (urb->unlinked)
 			goto return_urb;
author maintainer
#15 lore raw

PATCH 16/105 USB: dummy-hcd: Fix erroneous synchronization change

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 7dbd8f4cabd96db5a50513de9d83a8105a5ffc81 upstream.

A recent change to the synchronization in dummy-hcd was incorrect. The issue was that dummy_udc_stop() contained no locking and therefore could race with various gadget driver callbacks, and the fix was to add locking and issue the callbacks with the private spinlock held.

UDC drivers aren't supposed to do this. Gadget driver callback routines are allowed to invoke functions in the UDC driver, and these functions will generally try to acquire the private spinlock. This would deadlock the driver.

The correct solution is to drop the spinlock before issuing callbacks, and avoid races by emulating the synchronize_irq() call that all real UDC drivers must perform in their ->udc_stop() routines after disabling interrupts. This involves adding a flag to dummy-hcd's private structure to keep track of whether interrupts are supposed to be enabled, and adding a counter to keep track of ongoing callbacks so that dummy_udc_stop() can wait for them all to finish.

A real UDC driver won't receive disconnect, reset, suspend, resume, or setup events once it has disabled interrupts. dummy-hcd will receive them but won't try to issue any gadget driver callbacks, which should be just as good.

Fixes f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
---
 drivers/usb/gadget/udc/dummy_hcd.c |   32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +30 -2
@@ -255,11 +255,13 @@ struct dummy {
 	 */
 	struct dummy_ep			ep[DUMMY_ENDPOINTS];
 	int				address;
+	int				callback_usage;
 	struct usb_gadget		gadget;
 	struct usb_gadget_driver	*driver;
 	struct dummy_request		fifo_req;
 	u8				fifo_buf[FIFO_SIZE];
 	u16				devstatus;
+	unsigned			ints_enabled:1;
 	unsigned			udc_suspended:1;
 	unsigned			pullup:1;
 
@@ -442,18 +444,27 @@ static void set_link_state(struct dummy_
 				(~dum_hcd->old_status) & dum_hcd->port_status;
 
 		/* Report reset and disconnect events to the driver */
-		if (dum->driver && (disconnect || reset)) {
+		if (dum->ints_enabled && (disconnect || reset)) {
 			stop_activity(dum);
+			++dum->callback_usage;
+			spin_unlock(&dum->lock);
 			if (reset)
 				usb_gadget_udc_reset(&dum->gadget, dum->driver);
 			else
 				dum->driver->disconnect(&dum->gadget);
+			spin_lock(&dum->lock);
+			--dum->callback_usage;
 		}
-	} else if (dum_hcd->active != dum_hcd->old_active) {
+	} else if (dum_hcd->active != dum_hcd->old_active &&
+			dum->ints_enabled) {
+		++dum->callback_usage;
+		spin_unlock(&dum->lock);
 		if (dum_hcd->old_active && dum->driver->suspend)
 			dum->driver->suspend(&dum->gadget);
 		else if (!dum_hcd->old_active &&  dum->driver->resume)
 			dum->driver->resume(&dum->gadget);
+		spin_lock(&dum->lock);
+		--dum->callback_usage;
 	}
 
 	dum_hcd->old_status = dum_hcd->port_status;
@@ -967,8 +978,11 @@ static int dummy_udc_start(struct usb_ga
 	 * can't enumerate without help from the driver we're binding.
 	 */
 
+	spin_lock_irq(&dum->lock);
 	dum->devstatus = 0;
 	dum->driver = driver;
+	dum->ints_enabled = 1;
+	spin_unlock_irq(&dum->lock);
 
 	return 0;
 }
@@ -979,6 +993,16 @@ static int dummy_udc_stop(struct usb_gad
 	struct dummy		*dum = dum_hcd->dum;
 
 	spin_lock_irq(&dum->lock);
+	dum->ints_enabled = 0;
+	stop_activity(dum);
+
+	/* emulate synchronize_irq(): wait for callbacks to finish */
+	while (dum->callback_usage > 0) {
+		spin_unlock_irq(&dum->lock);
+		usleep_range(1000, 2000);
+		spin_lock_irq(&dum->lock);
+	}
+
 	dum->driver = NULL;
 	spin_unlock_irq(&dum->lock);
 
@@ -1524,6 +1548,8 @@ static struct dummy_ep *find_endpoint(st
 	if (!is_active((dum->gadget.speed == USB_SPEED_SUPER ?
 			dum->ss_hcd : dum->hs_hcd)))
 		return NULL;
+	if (!dum->ints_enabled)
+		return NULL;
 	if ((address & ~USB_DIR_IN) == 0)
 		return &dum->ep[0];
 	for (i = 1; i < DUMMY_ENDPOINTS; i++) {
@@ -1865,10 +1891,12 @@ restart:
 			 * until setup() returns; no reentrancy issues etc.
 			 */
 			if (value > 0) {
+				++dum->callback_usage;
 				spin_unlock(&dum->lock);
 				value = dum->driver->setup(&dum->gadget,
 						&setup);
 				spin_lock(&dum->lock);
+				--dum->callback_usage;
 
 				if (value >= 0) {
 					/* no delays (max 64KB data stage) */
author maintainer
#16 lore raw

PATCH 17/105 USB: devio: Dont corrupt user memory

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 upstream.

The user buffer has "uurb->buffer_length" bytes. If the kernel has more information than that, we should truncate it instead of writing past the end of the user's buffer. I added a WARN_ONCE() to help the user debug the issue.

---
 drivers/usb/core/devio.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/core/devio.c +5 -1
@@ -1577,7 +1577,11 @@ static int proc_do_submiturb(struct usb_
 			totlen += isopkt[u].length;
 		}
 		u *= sizeof(struct usb_iso_packet_descriptor);
-		uurb->buffer_length = totlen;
+		if (totlen <= uurb->buffer_length)
+			uurb->buffer_length = totlen;
+		else
+			WARN_ONCE(1, "uurb->buffer_length is too short %d vs %d",
+				  totlen, uurb->buffer_length);
 		break;
 
 	default:
author maintainer
#17 lore raw

PATCH 18/105 usb: gadget: mass_storage: set msg_registered after msg registered

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Li Jun <[email protected]>

commit 8e55d30322c6a0ef746c256a1beda9c73ecb27a6 upstream.

If there is no UDC available, the msg register will fail and this flag will not be set, but the driver is already added into pending driver list, then the module removal modprobe -r can not remove the driver from the pending list.

---
 drivers/usb/gadget/legacy/mass_storage.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/gadget/legacy/mass_storage.c +6 -2
@@ -210,7 +210,6 @@ static int msg_bind(struct usb_composite
 	usb_composite_overwrite_options(cdev, &coverwrite);
 	dev_info(&cdev->gadget->dev,
 		 DRIVER_DESC ", version: " DRIVER_VERSION "\n");
-	set_bit(0, &msg_registered);
 	return 0;
 
 fail_otg_desc:
@@ -257,7 +256,12 @@ MODULE_LICENSE("GPL");
 
 static int __init msg_init(void)
 {
-	return usb_composite_probe(&msg_driver);
+	int ret;
+
+	ret = usb_composite_probe(&msg_driver);
+	set_bit(0, &msg_registered);
+
+	return ret;
 }
 module_init(msg_init);
 
author maintainer
#18 lore raw

PATCH 19/105 USB: g_mass_storage: Fix deadlock when driver is unbound

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 1fbbb78f25d1291274f320462bf6908906f538db upstream.

As a holdover from the old g_file_storage gadget, the g_mass_storage legacy gadget driver attempts to unregister itself when its main operating thread terminates (if it hasn't been unregistered already). This is not strictly necessary; it was never more than an attempt to have the gadget fail cleanly if something went wrong and the main thread was killed.

However, now that the UDC core manages gadget drivers independently of UDC drivers, this scheme doesn't work any more. A simple test:

modprobe dummy-hcd
modprobe g-mass-storage file=...
rmmod dummy-hcd

ends up in a deadlock with the following backtrace:

sysrq: SysRq : Show Blocked State
task PC stack pid father
file-storage D 0 1130 2 0x00000000

 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_preempt_disabled+0xd/0xf
  __mutex_lock.isra.1+0x129/0x224
  ? _raw_spin_unlock_irqrestore+0x12/0x14
  __mutex_lock_slowpath+0x12/0x14
  mutex_lock+0x28/0x2b
  usb_gadget_unregister_driver+0x29/0x9b [udc_core]
  usb_composite_unregister+0x10/0x12 [libcomposite]
  msg_cleanup+0x1d/0x20 [g_mass_storage]
  msg_thread_exits+0xd/0xdd7 [g_mass_storage]
  fsg_main_thread+0x1395/0x13d6 [usb_f_mass_storage]
  ? __schedule+0x573/0x58c
  kthread+0xd9/0xdb
  ? do_set_interface+0x25c/0x25c [usb_f_mass_storage]
  ? init_completion+0x1e/0x1e
  ret_from_fork+0x19/0x24
 rmmod           D    0  1155    683 0x00000000
 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_timeout+0x26/0xbc
  ? __schedule+0x573/0x58c
  do_wait_for_common+0xb3/0x128
  ? usleep_range+0x81/0x81
  ? wake_up_q+0x3f/0x3f
  wait_for_common+0x2e/0x45
  wait_for_completion+0x17/0x19
  fsg_common_put+0x34/0x81 [usb_f_mass_storage]
  fsg_free_inst+0x13/0x1e [usb_f_mass_storage]
  usb_put_function_instance+0x1a/0x25 [libcomposite]
  msg_unbind+0x2a/0x42 [g_mass_storage]
  __composite_unbind+0x4a/0x6f [libcomposite]
  composite_unbind+0x12/0x14 [libcomposite]
  usb_gadget_remove_driver+0x4f/0x77 [udc_core]
  usb_del_gadget_udc+0x52/0xcc [udc_core]
  dummy_udc_remove+0x27/0x2c [dummy_hcd]
  platform_drv_remove+0x1d/0x31
  device_release_driver_internal+0xe9/0x16d
  device_release_driver+0x11/0x13
  bus_remove_device+0xd2/0xe2
  device_del+0x19f/0x221
  ? selinux_capable+0x22/0x27
  platform_device_del+0x21/0x63
  platform_device_unregister+0x10/0x1a
  cleanup+0x20/0x817 [dummy_hcd]
  SyS_delete_module+0x10c/0x197
  ? ____fput+0xd/0xf
  ? task_work_run+0x55/0x62
  ? prepare_exit_to_usermode+0x65/0x75
  do_fast_syscall_32+0x86/0xc3
  entry_SYSENTER_32+0x4e/0x7c

What happens is that removing the dummy-hcd driver causes the UDC core to unbind the gadget driver, which it does while holding the udc_lock mutex. The unbind routine in g_mass_storage tells the main thread to exit and waits for it to terminate.

But as mentioned above, when the main thread exits it tries to unregister the mass-storage function driver. Via the composite framework this ends up calling usb_gadget_unregister_driver(), which tries to acquire the udc_lock mutex. The result is deadlock.

The simplest way to fix the problem is not to be so clever: The main thread doesn't have to unregister the function driver. The side effects won't be so terrible; if the gadget is still attached to a USB host when the main thread is killed, it will appear to the host as though the gadget's firmware has crashed -- a reasonably accurate interpretation, and an all-too-common occurrence for USB mass-storage devices.

In fact, the code to unregister the driver when the main thread exits is specific to g-mass-storage; it is not used when f-mass-storage is included as a function in a larger composite device. Therefore the entire mechanism responsible for this (the fsg_operations structure with its ->thread_exits method, the fsg_common_set_ops() routine, and the msg_thread_exits() callback routine) can all be eliminated. Even the msg_registered bitflag can be removed, because now the driver is unregistered in only one place rather than in two places.

---
 drivers/usb/gadget/function/f_mass_storage.c |   29 +++++++--------------------
 drivers/usb/gadget/function/f_mass_storage.h |   14 -------------
 drivers/usb/gadget/legacy/mass_storage.c     |   26 ++----------------------
 3 files changed, 11 insertions(+), 58 deletions(-)
drivers/usb/gadget/function/f_mass_storage.c +8 -21
@@ -306,8 +306,6 @@ struct fsg_common {
 	struct completion	thread_notifier;
 	struct task_struct	*thread_task;
 
-	/* Callback functions. */
-	const struct fsg_operations	*ops;
 	/* Gadget's private data. */
 	void			*private_data;
 
@@ -2505,6 +2503,7 @@ static void handle_exception(struct fsg_
 static int fsg_main_thread(void *common_)
 {
 	struct fsg_common	*common = common_;
+	int			i;
 
 	/*
 	 * Allow the thread to be killed by a signal, but set the signal mask
@@ -2566,21 +2565,16 @@ static int fsg_main_thread(void *common_
 	common->thread_task = NULL;
 	spin_unlock_irq(&common->lock);
 
-	if (!common->ops || !common->ops->thread_exits
-	 || common->ops->thread_exits(common) < 0) {
-		int i;
-
-		down_write(&common->filesem);
-		for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
-			struct fsg_lun *curlun = common->luns[i];
-			if (!curlun || !fsg_lun_is_open(curlun))
-				continue;
+	/* Eject media from all LUNs */
 
+	down_write(&common->filesem);
+	for (i = 0; i < ARRAY_SIZE(common->luns); i++) {
+		struct fsg_lun *curlun = common->luns[i];
+
+		if (curlun && fsg_lun_is_open(curlun))
 			fsg_lun_close(curlun);
-			curlun->unit_attention_data = SS_MEDIUM_NOT_PRESENT;
-		}
-		up_write(&common->filesem);
 	}
+	up_write(&common->filesem);
 
 	/* Let fsg_unbind() know the thread has exited */
 	complete_and_exit(&common->thread_notifier, 0);
@@ -2770,13 +2764,6 @@ void fsg_common_remove_luns(struct fsg_c
 }
 EXPORT_SYMBOL_GPL(fsg_common_remove_luns);
 
-void fsg_common_set_ops(struct fsg_common *common,
-			const struct fsg_operations *ops)
-{
-	common->ops = ops;
-}
-EXPORT_SYMBOL_GPL(fsg_common_set_ops);
-
 void fsg_common_free_buffers(struct fsg_common *common)
 {
 	_fsg_common_free_buffers(common->buffhds, common->fsg_num_buffers);
drivers/usb/gadget/function/f_mass_storage.h +0 -14
@@ -60,17 +60,6 @@ struct fsg_module_parameters {
 struct fsg_common;
 
 /* FSF callback functions */
-struct fsg_operations {
-	/*
-	 * Callback function to call when thread exits.  If no
-	 * callback is set or it returns value lower then zero MSF
-	 * will force eject all LUNs it operates on (including those
-	 * marked as non-removable or with prevent_medium_removal flag
-	 * set).
-	 */
-	int (*thread_exits)(struct fsg_common *common);
-};
-
 struct fsg_lun_opts {
 	struct config_group group;
 	struct fsg_lun *lun;
@@ -142,9 +131,6 @@ void fsg_common_remove_lun(struct fsg_lu
 
 void fsg_common_remove_luns(struct fsg_common *common);
 
-void fsg_common_set_ops(struct fsg_common *common,
-			const struct fsg_operations *ops);
-
 int fsg_common_create_lun(struct fsg_common *common, struct fsg_lun_config *cfg,
 			  unsigned int id, const char *name,
 			  const char **name_pfx);
drivers/usb/gadget/legacy/mass_storage.c +3 -23
@@ -107,15 +107,6 @@ static unsigned int fsg_num_buffers = CO
 
 FSG_MODULE_PARAMETERS(/* no prefix */, mod_data);
 
-static unsigned long msg_registered;
-static void msg_cleanup(void);
-
-static int msg_thread_exits(struct fsg_common *common)
-{
-	msg_cleanup();
-	return 0;
-}
-
 static int msg_do_config(struct usb_configuration *c)
 {
 	struct fsg_opts *opts;
@@ -154,9 +145,6 @@ static struct usb_configuration msg_conf
 
 static int msg_bind(struct usb_composite_dev *cdev)
 {
-	static const struct fsg_operations ops = {
-		.thread_exits = msg_thread_exits,
-	};
 	struct fsg_opts *opts;
 	struct fsg_config config;
 	int status;
@@ -173,8 +161,6 @@ static int msg_bind(struct usb_composite
 	if (status)
 		goto fail;
 
-	fsg_common_set_ops(opts->common, &ops);
-
 	status = fsg_common_set_cdev(opts->common, cdev, config.can_stall);
 	if (status)
 		goto fail_set_cdev;
@@ -256,18 +242,12 @@ MODULE_LICENSE("GPL");
 
 static int __init msg_init(void)
 {
-	int ret;
-
-	ret = usb_composite_probe(&msg_driver);
-	set_bit(0, &msg_registered);
-
-	return ret;
+	return usb_composite_probe(&msg_driver);
 }
 module_init(msg_init);
 
-static void msg_cleanup(void)
+static void __exit msg_cleanup(void)
 {
-	if (test_and_clear_bit(0, &msg_registered))
-		usb_composite_unregister(&msg_driver);
+	usb_composite_unregister(&msg_driver);
 }
 module_exit(msg_cleanup);
author maintainer
#19 lore raw

PATCH 20/105 USB: uas: fix bug in handling of alternate settings

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

commit 786de92b3cb26012d3d0f00ee37adf14527f35c4 upstream.

The uas driver has a subtle bug in the way it handles alternate settings. The uas_find_uas_alt_setting() routine returns an altsetting value (the bAlternateSetting number in the descriptor), but uas_use_uas_driver() then treats that value as an index to the intf->altsetting array, which it isn't.

Normally this doesn't cause any problems because the various alternate settings have bAlternateSetting values 0, 1, 2, ..., so the value is equal to the index in the array. But this is not guaranteed, and Andrey Konovalov used the syzkaller fuzzer with KASAN to get a slab-out-of-bounds error by violating this assumption.

This patch fixes the bug by making uas_find_uas_alt_setting() return a pointer to the altsetting entry rather than either the value or the index. Pointers are less subject to misinterpretation.

---
 drivers/usb/storage/uas-detect.h |   15 ++++++++-------
 drivers/usb/storage/uas.c        |   10 +++++-----
 2 files changed, 13 insertions(+), 12 deletions(-)
drivers/usb/storage/uas-detect.h +8 -7
@@ -9,7 +9,8 @@ static int uas_is_interface(struct usb_h
 		intf->desc.bInterfaceProtocol == USB_PR_UAS);
 }
 
-static int uas_find_uas_alt_setting(struct usb_interface *intf)
+static struct usb_host_interface *uas_find_uas_alt_setting(
+		struct usb_interface *intf)
 {
 	int i;
 
@@ -17,10 +18,10 @@ static int uas_find_uas_alt_setting(stru
 		struct usb_host_interface *alt = &intf->altsetting[i];
 
 		if (uas_is_interface(alt))
-			return alt->desc.bAlternateSetting;
+			return alt;
 	}
 
-	return -ENODEV;
+	return NULL;
 }
 
 static int uas_find_endpoints(struct usb_host_interface *alt,
@@ -58,14 +59,14 @@ static int uas_use_uas_driver(struct usb
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
 	unsigned long flags = id->driver_info;
-	int r, alt;
-
+	struct usb_host_interface *alt;
+	int r;
 
 	alt = uas_find_uas_alt_setting(intf);
-	if (alt < 0)
+	if (!alt)
 		return 0;
 
-	r = uas_find_endpoints(&intf->altsetting[alt], eps);
+	r = uas_find_endpoints(alt, eps);
 	if (r < 0)
 		return 0;
 
drivers/usb/storage/uas.c +5 -5
@@ -873,14 +873,14 @@ MODULE_DEVICE_TABLE(usb, uas_usb_ids);
 static int uas_switch_interface(struct usb_device *udev,
 				struct usb_interface *intf)
 {
-	int alt;
+	struct usb_host_interface *alt;
 
 	alt = uas_find_uas_alt_setting(intf);
-	if (alt < 0)
-		return alt;
+	if (!alt)
+		return -ENODEV;
 
-	return usb_set_interface(udev,
-			intf->altsetting[0].desc.bInterfaceNumber, alt);
+	return usb_set_interface(udev, alt->desc.bInterfaceNumber,
+			alt->desc.bAlternateSetting);
 }
 
 static int uas_configure_endpoints(struct uas_dev_info *devinfo)
author maintainer
#20 lore raw

PATCH 21/105 USB: core: harden cdc_parse_cdc_header

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <[email protected]>

commit 2e1c42391ff2556387b3cb6308b24f6f65619feb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for the cdc_parse_cdc_header function. He writes:
It looks like cdc_parse_cdc_header() doesn't validate buflen before accessing buffer[1], buffer[2] and so on. The only check present is while (buflen > 0).

So fix this issue up by properly validating the buffer length matches what the descriptor says it is.

---
 drivers/usb/core/message.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/core/message.c +4 -0
@@ -2068,6 +2068,10 @@ int cdc_parse_cdc_header(struct usb_cdc_
 			elength = 1;
 			goto next_desc;
 		}
+		if ((buflen < elength) || (elength < 3)) {
+			dev_err(&intf->dev, "invalid descriptor buffer length\n");
+			break;
+		}
 		if (buffer[1] != USB_DT_CS_INTERFACE) {
 			dev_err(&intf->dev, "skipping garbage\n");
 			goto next_desc;
author maintainer
#21 lore raw

PATCH 22/105 usb: Increase quirk delay for USB devices

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Fleytman <[email protected]>

commit b2a542bbb3081dbd64acc8929c140d196664c406 upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams.

The workaround is introducing delay for some USB operations.

According to our testing, delay introduced by original commit is not long enough and in rare cases we still see issues described by the aforementioned commit.

This patch increases delays introduced by original commit. Having this patch applied we do not see those problems anymore.

---
 drivers/usb/core/config.c |    2 +-
 drivers/usb/core/hub.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/usb/core/config.c +1 -1
@@ -847,7 +847,7 @@ int usb_get_configuration(struct usb_dev
 		}
 
 		if (dev->quirks & USB_QUIRK_DELAY_INIT)
-			msleep(100);
+			msleep(200);
 
 		result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
 		    bigbuffer, length);
drivers/usb/core/hub.c +1 -1
@@ -4828,7 +4828,7 @@ static void hub_port_connect(struct usb_
 			goto loop;
 
 		if (udev->quirks & USB_QUIRK_DELAY_INIT)
-			msleep(1000);
+			msleep(2000);
 
 		/* consecutive bus-powered hubs aren't reliable; they can
 		 * violate the voltage drop budget.  if the new child has
author maintainer
#22 lore raw

PATCH 23/105 USB: fix out-of-bounds in usb_set_configuration

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <[email protected]>

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes:
It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount.

And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller...

---
 drivers/usb/core/config.c    |   14 +++++++++++---
 include/uapi/linux/usb/ch9.h |    1 +
 2 files changed, 12 insertions(+), 3 deletions(-)
drivers/usb/core/config.c +11 -3
@@ -638,15 +638,23 @@ static int usb_parse_configuration(struc
 
 		} else if (header->bDescriptorType ==
 				USB_DT_INTERFACE_ASSOCIATION) {
+			struct usb_interface_assoc_descriptor *d;
+
+			d = (struct usb_interface_assoc_descriptor *)header;
+			if (d->bLength < USB_DT_INTERFACE_ASSOCIATION_SIZE) {
+				dev_warn(ddev,
+					 "config %d has an invalid interface association descriptor of length %d, skipping\n",
+					 cfgno, d->bLength);
+				continue;
+			}
+
 			if (iad_num == USB_MAXIADS) {
 				dev_warn(ddev, "found more Interface "
 					       "Association Descriptors "
 					       "than allocated for in "
 					       "configuration %d\n", cfgno);
 			} else {
-				config->intf_assoc[iad_num] =
-					(struct usb_interface_assoc_descriptor
-					*)header;
+				config->intf_assoc[iad_num] = d;
 				iad_num++;
 			}
 
include/uapi/linux/usb/ch9.h +1 -0
@@ -759,6 +759,7 @@ struct usb_interface_assoc_descriptor {
 	__u8  iFunction;
 } __attribute__ ((packed));
 
+#define USB_DT_INTERFACE_ASSOCIATION_SIZE	8
 
 /*-------------------------------------------------------------------------*/
 
author maintainer
#23 lore raw

PATCH 24/105 xhci: fix finding correct bus_state structure for USB 3.1 hosts

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mathias Nyman <[email protected]>

commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

---
 drivers/usb/host/xhci.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci.h +1 -1
@@ -1509,7 +1509,7 @@ struct xhci_bus_state {
 
 static inline unsigned int hcd_index(struct usb_hcd *hcd)
 {
-	if (hcd->speed == HCD_USB3)
+	if (hcd->speed >= HCD_USB3)
 		return 0;
 	else
 		return 1;
author maintainer
#24 lore raw

PATCH 25/105 xhci: Fix sleeping with spin_lock_irq() held in ASmedia 1042A workaround

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mathias Nyman <[email protected]>

commit 4ec1cd3eeeee7ccc35681270da028dbc29ca7bbd upstream.

The flow control workaround for ASM1042A xHC hosts sleeps between register polling. The workaround gets called in several places, among them with spin_lock_irq() held when xHC host is resumed or hoplug removed.

This was noticed as kernel panics at resume on a Dell XPS15 9550 with TB16 thunderbolt dock.

Avoid sleeping with spin_lock_irq() held, use udelay() instead

The original workaround was added to 4.9 and 4.12 stable releases, this patch needs to be applied to those as well.

Fixes 9da5a1092b13 ("xhci: Bad Ethernet performance plugged in ASM1042A host")
---
 drivers/usb/host/pci-quirks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/pci-quirks.c +1 -1
@@ -447,7 +447,7 @@ static int usb_asmedia_wait_write(struct
 		if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
 			return 0;
 
-		usleep_range(40, 60);
+		udelay(50);
 	}
 
 	dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
author maintainer
#25 lore raw

PATCH 26/105 xhci: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mathias Nyman <[email protected]>

commit 7bea22b124d77845c85a62eaa29a85ba6cc2f899 upstream.

A SuperSpeedPlus roothub needs to have the Link Protocol (LP) bit set in the bmSublinkSpeedAttr[] entry of a SuperSpeedPlus descriptor.

If the xhci controller has an optional Protocol Speed ID (PSI) table then that will be used as a base to create the roothub SuperSpeedPlus descriptor.
The PSI table does not however necessary contain the LP bit so we need to set it manually.

Check the psi speed and set LP bit if speed is 10Gbps or higher. We're not setting it for 5 to 10Gbps as USB 3.1 specification always mention SuperSpeedPlus for 10Gbps or higher, and some SSIC USB 3.0 speeds can be over 5Gbps, such as SSIC-G3B-L1 at 5830 Mbps

---
 drivers/usb/host/xhci-hub.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-hub.c +10 -1
@@ -112,7 +112,7 @@ static int xhci_create_usb3_bos_desc(str
 
 	/* If PSI table exists, add the custom speed attributes from it */
 	if (usb3_1 && xhci->usb3_rhub.psi_count) {
-		u32 ssp_cap_base, bm_attrib, psi;
+		u32 ssp_cap_base, bm_attrib, psi, psi_mant, psi_exp;
 		int offset;
 
 		ssp_cap_base = USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE;
@@ -139,6 +139,15 @@ static int xhci_create_usb3_bos_desc(str
 		for (i = 0; i < xhci->usb3_rhub.psi_count; i++) {
 			psi = xhci->usb3_rhub.psi[i];
 			psi &= ~USB_SSP_SUBLINK_SPEED_RSVD;
+			psi_exp = XHCI_EXT_PORT_PSIE(psi);
+			psi_mant = XHCI_EXT_PORT_PSIM(psi);
+
+			/* Shift to Gbps and set SSP Link BIT(14) if 10Gpbs */
+			for (; psi_exp < 3; psi_exp++)
+				psi_mant /= 1000;
+			if (psi_mant >= 10)
+				psi |= BIT(14);
+
 			if ((psi & PLT_MASK) == PLT_SYM) {
 			/* Symmetric, create SSA RX and TX from one PSI entry */
 				put_unaligned_le32(psi, &buf[offset]);
author maintainer
#26 lore raw

PATCH 27/105 Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Kai-Heng Feng <[email protected]>

commit bcd6a7aa13800afc1418e6b29d944d882214939a upstream.

This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f.

Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to function after enabling runtime PM.

All boards with this chipsets will be affected, so revert the commit.

The original patch was added to stable 4.9, 4.11 and 4.12 and needs to reverted from there as well

---
 drivers/usb/host/xhci-hub.c |    3 ---
 drivers/usb/host/xhci-pci.c |   12 ------------
 drivers/usb/host/xhci.h     |    2 +-
 3 files changed, 1 insertion(+), 16 deletions(-)
drivers/usb/host/xhci-hub.c +0 -3
@@ -1360,9 +1360,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd
 				t2 |= PORT_WKOC_E | PORT_WKCONN_E;
 				t2 &= ~PORT_WKDISC_E;
 			}
-			if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&
-			    (hcd->speed < HCD_USB3))
-				t2 &= ~PORT_WAKE_BITS;
 		} else
 			t2 &= ~PORT_WAKE_BITS;
 
drivers/usb/host/xhci-pci.c +0 -12
@@ -54,11 +54,6 @@
 #define PCI_DEVICE_ID_INTEL_APL_XHCI			0x5aa8
 #define PCI_DEVICE_ID_INTEL_DNV_XHCI			0x19d0
 
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_4			0x43b9
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_3			0x43ba
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_2			0x43bb
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_1			0x43bc
-
 #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI		0x1142
 
 static const char hcd_name[] = "xhci_hcd";
@@ -142,13 +137,6 @@ static void xhci_pci_quirks(struct devic
 	if (pdev->vendor == PCI_VENDOR_ID_AMD)
 		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 
-	if ((pdev->vendor == PCI_VENDOR_ID_AMD) &&
-		((pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4) ||
-		(pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_3) ||
-		(pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_2) ||
-		(pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_1)))
-		xhci->quirks |= XHCI_U2_DISABLE_WAKE;
-
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_INTEL_HOST;
drivers/usb/host/xhci.h +1 -1
@@ -1660,7 +1660,7 @@ struct xhci_hcd {
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED	(1 << 25)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7	(1 << 26)
-#define XHCI_U2_DISABLE_WAKE	(1 << 27)
+/* Reserved. It was XHCI_U2_DISABLE_WAKE */
 #define XHCI_ASMEDIA_MODIFY_FLOWCONTROL	(1 << 28)
 
 	unsigned int		num_active_eps;
author maintainer
#27 lore raw

PATCH 28/105 iio: adc: twl4030: Fix an error handling path in twl4030_madc_probe()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christophe JAILLET <[email protected]>

commit 245a396a9b1a67ac5c3228737c261b3e48708a2a upstream.

If 'devm_regulator_get()' fails, we should go through the existing error handling path instead of returning directly, as done is all the other error handling paths in this function.

Fixes 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
---
 drivers/iio/adc/twl4030-madc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/adc/twl4030-madc.c +4 -2
@@ -866,8 +866,10 @@ static int twl4030_madc_probe(struct pla
 
 	/* Enable 3v1 bias regulator for MADC[3:6] */
 	madc->usb3v1 = devm_regulator_get(madc->dev, "vusb3v1");
-	if (IS_ERR(madc->usb3v1))
-		return -ENODEV;
+	if (IS_ERR(madc->usb3v1)) {
+		ret = -ENODEV;
+		goto err_i2c;
+	}
 
 	ret = regulator_enable(madc->usb3v1);
 	if (ret)
author maintainer
#28 lore raw

PATCH 29/105 iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of twl4030_madc_probe()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christophe JAILLET <[email protected]>

commit 7f70be6e4025db0551e6863e7eb9cca07122695c upstream.

Commit 7cc97d77ee8a has introduced a call to 'regulator_disable()' in the .remove function.
So we should also have such a call in the .probe function in case of error after a successful 'regulator_enable()' call.

Add a new label for that and use it.

Fixes 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
---
 drivers/iio/adc/twl4030-madc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/iio/adc/twl4030-madc.c +3 -1
@@ -878,11 +878,13 @@ static int twl4030_madc_probe(struct pla
 	ret = iio_device_register(iio_dev);
 	if (ret) {
 		dev_err(&pdev->dev, "could not register iio device\n");
-		goto err_i2c;
+		goto err_usb3v1;
 	}
 
 	return 0;
 
+err_usb3v1:
+	regulator_disable(madc->usb3v1);
 err_i2c:
 	twl4030_madc_set_current_generator(madc, 0, 0);
 err_current_generator:
author maintainer
#29 lore raw

PATCH 30/105 iio: ad_sigma_delta: Implement a dedicated reset function

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dragos Bogdan <[email protected]>

commit 7fc10de8d49a748c476532c9d8e8fe19e548dd67 upstream.

Since most of the SD ADCs have the option of reseting the serial interface by sending a number of SCLKs with CS = 0 and DIN = 1, a dedicated function that can do this is usefull.

Needed for the patch: iio: ad7793: Fix the serial interface reset

---
 drivers/iio/adc/ad_sigma_delta.c       |   28 ++++++++++++++++++++++++++++
 include/linux/iio/adc/ad_sigma_delta.h |    3 +++
 2 files changed, 31 insertions(+)
drivers/iio/adc/ad_sigma_delta.c +28 -0
@@ -177,6 +177,34 @@ out:
 }
 EXPORT_SYMBOL_GPL(ad_sd_read_reg);
 
+/**
+ * ad_sd_reset() - Reset the serial interface
+ *
+ * @sigma_delta: The sigma delta device
+ * @reset_length: Number of SCLKs with DIN = 1
+ *
+ * Returns 0 on success, an error code otherwise.
+ **/
+int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
+	unsigned int reset_length)
+{
+	uint8_t *buf;
+	unsigned int size;
+	int ret;
+
+	size = DIV_ROUND_UP(reset_length, 8);
+	buf = kcalloc(size, sizeof(*buf), GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	memset(buf, 0xff, size);
+	ret = spi_write(sigma_delta->spi, buf, size);
+	kfree(buf);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(ad_sd_reset);
+
 static int ad_sd_calibrate(struct ad_sigma_delta *sigma_delta,
 	unsigned int mode, unsigned int channel)
 {
include/linux/iio/adc/ad_sigma_delta.h +3 -0
@@ -111,6 +111,9 @@ int ad_sd_write_reg(struct ad_sigma_delt
 int ad_sd_read_reg(struct ad_sigma_delta *sigma_delta, unsigned int reg,
 	unsigned int size, unsigned int *val);
 
+int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
+	unsigned int reset_length);
+
 int ad_sigma_delta_single_conversion(struct iio_dev *indio_dev,
 	const struct iio_chan_spec *chan, int *val);
 int ad_sd_calibrate_all(struct ad_sigma_delta *sigma_delta,
author maintainer
#30 lore raw

PATCH 31/105 staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Popa <[email protected]>

commit f790923f146140a261ad211e5baf75d169f16fb2 upstream.

Depends on: 691c4b95d1 ("iio: ad_sigma_delta: Implement a dedicated reset function")

SPI host drivers can use DMA to transfer data, so the buffer should be properly allocated. Keeping it on the stack could cause an undefined behavior.

The dedicated reset function solves this issue.

---
 drivers/staging/iio/adc/ad7192.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/staging/iio/adc/ad7192.c +1 -3
@@ -222,11 +222,9 @@ static int ad7192_setup(struct ad7192_st
 	struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
 	unsigned long long scale_uv;
 	int i, ret, id;
-	u8 ones[6];
 
 	/* reset the serial interface */
-	memset(&ones, 0xFF, 6);
-	ret = spi_write(st->sd.spi, &ones, 6);
+	ret = ad_sd_reset(&st->sd, 48);
 	if (ret < 0)
 		goto out;
 	usleep_range(500, 1000); /* Wait for at least 500us */
author maintainer
#31 lore raw

PATCH 32/105 iio: core: Return error for failed read_reg

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Matt Fornero <[email protected]>

commit 3d62c78a6eb9a7d67bace9622b66ad51e81c5f9b upstream.

If an IIO device returns an error code for a read access via debugfs, it is currently ignored by the IIO core (other than emitting an error message). Instead, return this error code to user space, so upper layers can detect it correctly.

---
 drivers/iio/industrialio-core.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/iio/industrialio-core.c +3 -1
@@ -306,8 +306,10 @@ static ssize_t iio_debugfs_read_reg(stru
 	ret = indio_dev->info->debugfs_reg_access(indio_dev,
 						  indio_dev->cached_reg_addr,
 						  0, &val);
-	if (ret)
+	if (ret) {
 		dev_err(indio_dev->dev.parent, "%s: read failed\n", __func__);
+		return ret;
+	}
 
 	len = snprintf(buf, sizeof(buf), "0x%X\n", val);
 
author maintainer
#32 lore raw

PATCH 33/105 IIO: BME280: Updates to Humidity readings need ctrl_reg write!

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Colin Parker <[email protected]>

commit 4b1f0c31f96c45e8521dd84aae50f2aa4aecfb7b upstream.

The ctrl_reg register needs to be written after any write to the humidity registers. The value written to the ctrl_reg register does not necessarily need to change, but a write operation must occur.

The regmap_update_bits functions will not write to a register if the register value matches the value to be written. This saves unnecessary bus operations. The change in this patch forces a bus write during the chip_config operation by switching to regmap_write_bits.

This will fix issues where the Humidity Sensor Oversampling bits are not updated after initialization.

---
 drivers/iio/pressure/bmp280-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/pressure/bmp280-core.c +1 -1
@@ -558,7 +558,7 @@ static int bmp280_chip_config(struct bmp
 	u8 osrs = BMP280_OSRS_TEMP_X(data->oversampling_temp + 1) |
 		  BMP280_OSRS_PRESS_X(data->oversampling_press + 1);
 
-	ret = regmap_update_bits(data->regmap, BMP280_REG_CTRL_MEAS,
+	ret = regmap_write_bits(data->regmap, BMP280_REG_CTRL_MEAS,
 				 BMP280_OSRS_TEMP_MASK |
 				 BMP280_OSRS_PRESS_MASK |
 				 BMP280_MODE_MASK,
author maintainer
#33 lore raw

PATCH 34/105 iio: ad7793: Fix the serial interface reset

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dragos Bogdan <[email protected]>

commit 7ee3b7ebcb74714df6d94c8f500f307e1ee5dda5 upstream.

The serial interface can be reset by writing 32 consecutive 1s to the device. 'ret' was initialized correctly but its value was overwritten when ad7793_check_platform_data() was called. Since a dedicated reset function is present now, it should be used instead.

Fixes 2edb769d246e ("iio:ad7793: Add support for the ad7798 and ad7799")
---
 drivers/iio/adc/ad7793.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/adc/ad7793.c +2 -2
@@ -257,7 +257,7 @@ static int ad7793_setup(struct iio_dev *
 	unsigned int vref_mv)
 {
 	struct ad7793_state *st = iio_priv(indio_dev);
-	int i, ret = -1;
+	int i, ret;
 	unsigned long long scale_uv;
 	u32 id;
 
@@ -266,7 +266,7 @@ static int ad7793_setup(struct iio_dev *
 		return ret;
 
 	/* reset the serial interface */
-	ret = spi_write(st->sd.spi, (u8 *)&ret, sizeof(ret));
+	ret = ad_sd_reset(&st->sd, 32);
 	if (ret < 0)
 		goto out;
 	usleep_range(500, 2000); /* Wait for at least 500us */
author maintainer
#34 lore raw

PATCH 35/105 iio: adc: mcp320x: Fix readout of negative voltages

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Lukas Wunner <[email protected]>

commit e6f4794371ee7cce1339e7ca9542f1e703c5f84a upstream.

Commit f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301") returns a signed voltage from mcp320x_adc_conversion() but neglects that the caller interprets a negative return value as failure. Only mcp3301 (and the upcoming mcp3550/1/3) is affected as the other chips are incapable of measuring negative voltages.

Fix and while at it, add mcp3301 to the list of supported chips at the top of the file.

Fixes f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301")
Cc Andrea Galbusera <[email protected]>
---
 drivers/iio/adc/mcp320x.c |   24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)
drivers/iio/adc/mcp320x.c +15 -9
@@ -17,6 +17,8 @@
  * MCP3204
  * MCP3208
  * ------------
+ * 13 bit converter
+ * MCP3301
  *
  * Datasheet can be found here:
  * http://ww1.microchip.com/downloads/en/DeviceDoc/21293C.pdf  mcp3001
@@ -96,7 +98,7 @@ static int mcp320x_channel_to_tx_data(in
 }
 
 static int mcp320x_adc_conversion(struct mcp320x *adc, u8 channel,
-				  bool differential, int device_index)
+				  bool differential, int device_index, int *val)
 {
 	int ret;
 
@@ -117,19 +119,25 @@ static int mcp320x_adc_conversion(struct
 
 	switch (device_index) {
 	case mcp3001:
-		return (adc->rx_buf[0] << 5 | adc->rx_buf[1] >> 3);
+		*val = (adc->rx_buf[0] << 5 | adc->rx_buf[1] >> 3);
+		return 0;
 	case mcp3002:
 	case mcp3004:
 	case mcp3008:
-		return (adc->rx_buf[0] << 2 | adc->rx_buf[1] >> 6);
+		*val = (adc->rx_buf[0] << 2 | adc->rx_buf[1] >> 6);
+		return 0;
 	case mcp3201:
-		return (adc->rx_buf[0] << 7 | adc->rx_buf[1] >> 1);
+		*val = (adc->rx_buf[0] << 7 | adc->rx_buf[1] >> 1);
+		return 0;
 	case mcp3202:
 	case mcp3204:
 	case mcp3208:
-		return (adc->rx_buf[0] << 4 | adc->rx_buf[1] >> 4);
+		*val = (adc->rx_buf[0] << 4 | adc->rx_buf[1] >> 4);
+		return 0;
 	case mcp3301:
-		return sign_extend32((adc->rx_buf[0] & 0x1f) << 8 | adc->rx_buf[1], 12);
+		*val = sign_extend32((adc->rx_buf[0] & 0x1f) << 8
+				    | adc->rx_buf[1], 12);
+		return 0;
 	default:
 		return -EINVAL;
 	}
@@ -150,12 +158,10 @@ static int mcp320x_read_raw(struct iio_d
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		ret = mcp320x_adc_conversion(adc, channel->address,
-			channel->differential, device_index);
-
+			channel->differential, device_index, val);
 		if (ret < 0)
 			goto out;
 
-		*val = ret;
 		ret = IIO_VAL_INT;
 		break;
 
author maintainer
#35 lore raw

PATCH 36/105 iio: adc: mcp320x: Fix oops on module unload

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Lukas Wunner <[email protected]>

commit 0964e40947a630a2a6f724e968246992f97bcf1c upstream.

The driver calls spi_get_drvdata() in its ->remove hook even though it has never called spi_set_drvdata(). Stack trace for posterity:

Unable to handle kernel NULL pointer dereference at virtual address 00000220
Internal error: Oops: 5 [#1] SMP ARM
[<8072f564>] (mutex_lock) from [<7f1400d0>] (iio_device_unregister+0x24/0x7c [industrialio])
[<7f1400d0>] (iio_device_unregister [industrialio]) from [<7f15e020>] (mcp320x_remove+0x20/0x30 [mcp320x])
[<7f15e020>] (mcp320x_remove [mcp320x]) from [<8055a8cc>] (spi_drv_remove+0x2c/0x44)
[<8055a8cc>] (spi_drv_remove) from [<805087bc>] (__device_release_driver+0x98/0x134)
[<805087bc>] (__device_release_driver) from [<80509180>] (driver_detach+0xdc/0xe0)
[<80509180>] (driver_detach) from [<8050823c>] (bus_remove_driver+0x5c/0xb0)
[<8050823c>] (bus_remove_driver) from [<80509ab0>] (driver_unregister+0x38/0x58)
[<80509ab0>] (driver_unregister) from [<7f15e69c>] (mcp320x_driver_exit+0x14/0x1c [mcp320x])
[<7f15e69c>] (mcp320x_driver_exit [mcp320x]) from [<801a78d0>] (SyS_delete_module+0x184/0x1d0)
[<801a78d0>] (SyS_delete_module) from [<80108100>] (ret_fast_syscall+0x0/0x1c)
Fixes f5ce4a7a9291 ("iio: adc: add driver for MCP3204/08 12-bit ADC")
Cc Oskar Andero <[email protected]>
---
 drivers/iio/adc/mcp320x.c |    1 +
 1 file changed, 1 insertion(+)
drivers/iio/adc/mcp320x.c +1 -0
@@ -318,6 +318,7 @@ static int mcp320x_probe(struct spi_devi
 	indio_dev->name = spi_get_device_id(spi)->name;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &mcp320x_info;
+	spi_set_drvdata(spi, indio_dev);
 
 	chip_info = &mcp320x_chip_infos[spi_get_device_id(spi)->driver_data];
 	indio_dev->channels = chip_info->channels;
author maintainer
#36 lore raw

PATCH 37/105 uwb: properly check kthread_run return value

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Andrey Konovalov <[email protected]>

commit bbf26183b7a6236ba602f4d6a2f7cade35bba043 upstream.

uwbd_start() calls kthread_run() and checks that the return value is not NULL. But the return value is not NULL in case kthread_run() fails, it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Also add a check to uwbd_stop().

---
 drivers/uwb/uwbd.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/uwb/uwbd.c +8 -4
@@ -302,18 +302,22 @@ static int uwbd(void *param)
 /** Start the UWB daemon */
 void uwbd_start(struct uwb_rc *rc)
 {
-	rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
-	if (rc->uwbd.task == NULL)
+	struct task_struct *task = kthread_run(uwbd, rc, "uwbd");
+	if (IS_ERR(task)) {
+		rc->uwbd.task = NULL;
 		printk(KERN_ERR "UWB: Cannot start management daemon; "
 		       "UWB won't work\n");
-	else
+	} else {
+		rc->uwbd.task = task;
 		rc->uwbd.pid = rc->uwbd.task->pid;
+	}
 }
 
 /* Stop the UWB daemon and free any unprocessed events */
 void uwbd_stop(struct uwb_rc *rc)
 {
-	kthread_stop(rc->uwbd.task);
+	if (rc->uwbd.task)
+		kthread_stop(rc->uwbd.task);
 	uwbd_flush(rc);
 }
 
author maintainer
#37 lore raw

PATCH 38/105 uwb: ensure that endpoint is interrupt

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Andrey Konovalov <[email protected]>

commit 70e743e4cec3733dc13559f6184b35d358b9ef3f upstream.

hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device:

usb 1-1: BOGUS urb xfer, pipe 1 != type 3

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bdc1a00 task.stack: ffff88006bde8000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282
RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000
RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a
RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff
R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f
R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90
FS:  0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0
Call Trace:
 hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
---[ end trace 55d741234124cfc3 ]---

Check that endpoint is interrupt.

Found by syzkaller.

---
 drivers/uwb/hwa-rc.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/uwb/hwa-rc.c +2 -0
@@ -825,6 +825,8 @@ static int hwarc_probe(struct usb_interf
 
 	if (iface->cur_altsetting->desc.bNumEndpoints < 1)
 		return -ENODEV;
+	if (!usb_endpoint_xfer_int(&iface->cur_altsetting->endpoint[0].desc))
+		return -ENODEV;
 
 	result = -ENOMEM;
 	uwb_rc = uwb_rc_alloc();
author maintainer
#38 lore raw

PATCH 39/105 staging: vchiq_2835_arm: Fix NULL ptr dereference in free_pagelist

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Wahren <[email protected]>

commit 974d4d03fc020af4fa4e9e72a86f0fefa37803c5 upstream.

This fixes a NULL pointer dereference on RPi 2 with multi_v7_defconfig. The function page_address() could return NULL with enabled CONFIG_HIGHMEM. So fix this by using kmap() instead.

Fixes 71bad7f08641 ("staging: add bcm2708 vchiq driver")
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c +4 -2
@@ -538,18 +538,20 @@ free_pagelist(PAGELIST_T *pagelist, int
 			if (head_bytes > actual)
 				head_bytes = actual;
 
-			memcpy((char *)page_address(pages[0]) +
+			memcpy((char *)kmap(pages[0]) +
 				pagelist->offset,
 				fragments,
 				head_bytes);
+			kunmap(pages[0]);
 		}
 		if ((actual >= 0) && (head_bytes < actual) &&
 			(tail_bytes != 0)) {
-			memcpy((char *)page_address(pages[num_pages - 1]) +
+			memcpy((char *)kmap(pages[num_pages - 1]) +
 				((pagelist->offset + actual) &
 				(PAGE_SIZE - 1) & ~(g_cache_line_size - 1)),
 				fragments + g_cache_line_size,
 				tail_bytes);
+			kunmap(pages[num_pages - 1]);
 		}
 
 		down(&g_free_fragments_mutex);
author maintainer
#39 lore raw

PATCH 40/105 mm, oom_reaper: skip mm structs with mmu notifiers

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michal Hocko <[email protected]>

commit 4d4bbd8526a8fbeb2c090ea360211fceff952383 upstream.

Andrea has noticed that the oom_reaper doesn't invalidate the range via mmu notifiers (mmu_notifier_invalidate_range_start/end) and that can corrupt the memory of the kvm guest for example.

tlb_flush_mmu_tlbonly already invokes mmu notifiers but that is not sufficient as per Andrea:

"mmu_notifier_invalidate_range cannot be used in replacement of
mmu_notifier_invalidate_range_start/end. For KVM mmu_notifier_invalidate_range is a noop and rightfully so. A MMU notifier implementation has to implement either ->invalidate_range method or the invalidate_range_start/end methods, not both. And if you implement invalidate_range_start/end like KVM is forced to do, calling mmu_notifier_invalidate_range in common code is a noop for KVM.

For those MMU notifiers that can get away only implementing ->invalidate_range, the ->invalidate_range is implicitly called by mmu_notifier_invalidate_range_end(). And only those secondary MMUs that share the same pagetable with the primary MMU (like AMD iommuv2) can get away only implementing ->invalidate_range"

As the callback is allowed to sleep and the implementation is out of hand of the MM it is safer to simply bail out if there is an mmu notifier registered. In order to not fail too early make the mm_has_notifiers check under the oom_lock and have a little nap before failing to give the current oom victim some more time to exit.

---
 include/linux/mmu_notifier.h |    5 +++++
 mm/oom_kill.c                |   16 ++++++++++++++++
 2 files changed, 21 insertions(+)
include/linux/mmu_notifier.h +5 -0
@@ -419,6 +419,11 @@ extern void mmu_notifier_synchronize(voi
 
 #else /* CONFIG_MMU_NOTIFIER */
 
+static inline int mm_has_notifiers(struct mm_struct *mm)
+{
+	return 0;
+}
+
 static inline void mmu_notifier_release(struct mm_struct *mm)
 {
 }
mm/oom_kill.c +16 -0
@@ -37,6 +37,7 @@
 #include <linux/ratelimit.h>
 #include <linux/kthread.h>
 #include <linux/init.h>
+#include <linux/mmu_notifier.h>
 
 #include <asm/tlb.h>
 #include "internal.h"
@@ -490,6 +491,21 @@ static bool __oom_reap_task_mm(struct ta
 		goto unlock_oom;
 	}
 
+	/*
+	 * If the mm has notifiers then we would need to invalidate them around
+	 * unmap_page_range and that is risky because notifiers can sleep and
+	 * what they do is basically undeterministic.  So let's have a short
+	 * sleep to give the oom victim some more time.
+	 * TODO: we really want to get rid of this ugly hack and make sure that
+	 * notifiers cannot block for unbounded amount of time and add
+	 * mmu_notifier_invalidate_range_{start,end} around unmap_page_range
+	 */
+	if (mm_has_notifiers(mm)) {
+		up_read(&mm->mmap_sem);
+		schedule_timeout_idle(HZ);
+		goto unlock_oom;
+	}
+
 	/*
 	 * increase mm_users only after we know we will reap something so
 	 * that the mmput_async is called only when we have reaped something
author maintainer
#40 lore raw

PATCH 41/105 lib/ratelimit.c: use deferred printk() version

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sergey Senozhatsky <[email protected]>

commit 656d61ce9666209c4c4a13c71902d3ee70d1ff6f upstream.

printk_ratelimit() invokes ___ratelimit() which may invoke a normal printk() (pr_warn() in this particular case) to warn about suppressed output. Given that printk_ratelimit() may be called from anywhere, that pr_warn() is dangerous - it may end up deadlocking the system. Fix ___ratelimit() by using deferred printk().

Sasha reported the following lockdep error:

: Unregister pv shared memory for cpu 8
: select_fallback_rq: 3 callbacks suppressed
: process 8583 (trinity-c78) no longer affine to cpu8 :
: ====================================================== : WARNING: possible circular locking dependency detected : 4.14.0-rc2-next-20170927+ #252 Not tainted
: ------------------------------------------------------ : migration/8/62 is trying to acquire lock:
: (&port_lock_key){-.-.}, at: serial8250_console_write() :
: but task is already holding lock:
: (&rq->lock){-.-.}, at: sched_cpu_dying()
:
: which lock already depends on the new lock.
:
:
: the existing dependency chain (in reverse order) is:
:
: -> #3 (&rq->lock){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock()
: task_fork_fair()
: sched_fork()
: copy_process.part.31()
: _do_fork()
: kernel_thread()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #2 (&p->pi_lock){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: try_to_wake_up()
: default_wake_function()
: woken_wake_function()
: __wake_up_common()
: __wake_up_common_lock()
: __wake_up()
: tty_wakeup()
: tty_port_default_wakeup()
: tty_port_tty_wakeup()
: uart_write_wakeup()
: serial8250_tx_chars()
: serial8250_handle_irq.part.25()
: serial8250_default_handle_irq()
: serial8250_interrupt()
: __handle_irq_event_percpu()
: handle_irq_event_percpu()
: handle_irq_event()
: handle_level_irq()
: handle_irq()
: do_IRQ()
: ret_from_intr()
: native_safe_halt()
: default_idle()
: arch_cpu_idle()
: default_idle_call()
: do_idle()
: cpu_startup_entry()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #1 (&tty->write_wait){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: __wake_up_common_lock()
: __wake_up()
: tty_wakeup()
: tty_port_default_wakeup()
: tty_port_tty_wakeup()
: uart_write_wakeup()
: serial8250_tx_chars()
: serial8250_handle_irq.part.25()
: serial8250_default_handle_irq()
: serial8250_interrupt()
: __handle_irq_event_percpu()
: handle_irq_event_percpu()
: handle_irq_event()
: handle_level_irq()
: handle_irq()
: do_IRQ()
: ret_from_intr()
: native_safe_halt()
: default_idle()
: arch_cpu_idle()
: default_idle_call()
: do_idle()
: cpu_startup_entry()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #0 (&port_lock_key){-.-.}:
: check_prev_add()
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: serial8250_console_write()
: univ8250_console_write()
: console_unlock()
: vprintk_emit()
: vprintk_default()
: vprintk_func()
: printk()
: ___ratelimit()
: __printk_ratelimit()
: select_fallback_rq()
: sched_cpu_dying()
: cpuhp_invoke_callback()
: take_cpu_down()
: multi_cpu_stop()
: cpu_stopper_thread()
: smpboot_thread_fn()
: kthread()
: ret_from_fork()
:
: other info that might help us debug this:
:
: Chain exists of:
: &port_lock_key --> &p->pi_lock --> &rq->lock
:
: Possible unsafe locking scenario:
:

 :        CPU0                    CPU1
 :        ----                    ----

: lock(&rq->lock);
: lock(&p->pi_lock);
: lock(&rq->lock);
: lock(&port_lock_key);
:
: *** DEADLOCK ***
:
: 4 locks held by migration/8/62:
: #0: (&p->pi_lock){-.-.}, at: sched_cpu_dying()
: #1: (&rq->lock){-.-.}, at: sched_cpu_dying()
: #2: (printk_ratelimit_state.lock){....}, at: ___ratelimit()
: #3: (console_lock){+.+.}, at: vprintk_emit()
:
: stack backtrace:
: CPU: 8 PID: 62 Comm: migration/8 Not tainted 4.14.0-rc2-next-20170927+ #252 : Call Trace:
: dump_stack()
: print_circular_bug()
: check_prev_add()
: ? add_lock_to_list.isra.26()
: ? check_usage()
: ? kvm_clock_read()
: ? kvm_sched_clock_read()
: ? sched_clock()
: ? check_preemption_disabled()
: __lock_acquire()
: ? __lock_acquire()
: ? add_lock_to_list.isra.26()
: ? debug_check_no_locks_freed()
: ? memcpy()
: lock_acquire()
: ? serial8250_console_write()
: _raw_spin_lock_irqsave()
: ? serial8250_console_write()
: serial8250_console_write()
: ? serial8250_start_tx()
: ? lock_acquire()
: ? memcpy()
: univ8250_console_write()
: console_unlock()
: ? __down_trylock_console_sem()
: vprintk_emit()
: vprintk_default()
: vprintk_func()
: printk()
: ? show_regs_print_info()
: ? lock_acquire()
: ___ratelimit()
: __printk_ratelimit()
: select_fallback_rq()
: sched_cpu_dying()
: ? sched_cpu_starting()
: ? rcutree_dying_cpu()
: ? sched_cpu_starting()
: cpuhp_invoke_callback()
: ? cpu_disable_common()
: take_cpu_down()
: ? trace_hardirqs_off_caller()
: ? cpuhp_invoke_callback()
: multi_cpu_stop()
: ? __this_cpu_preempt_check()
: ? cpu_stop_queue_work()
: cpu_stopper_thread()
: ? cpu_stop_create()
: smpboot_thread_fn()
: ? sort_range()
: ? schedule()
: ? __kthread_parkme()
: kthread()
: ? sort_range()
: ? kthread_create_on_node()
: ret_from_fork()
: process 9121 (trinity-c78) no longer affine to cpu8
: smpboot: CPU 8 is now offline

Fixes 6b1d174b0c27b ("ratelimit: extend to print suppressed messages on release")
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc Steven Rostedt <[email protected]>
---
 lib/ratelimit.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
lib/ratelimit.c +3 -1
@@ -48,7 +48,9 @@ int ___ratelimit(struct ratelimit_state
 	if (time_is_before_jiffies(rs->begin + rs->interval)) {
 		if (rs->missed) {
 			if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
-				pr_warn("%s: %d callbacks suppressed\n", func, rs->missed);
+				printk_deferred(KERN_WARNING
+						"%s: %d callbacks suppressed\n",
+						func, rs->missed);
 				rs->missed = 0;
 			}
 		}
author maintainer
#41 lore raw

PATCH 42/105 lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Casey Schaufler <[email protected]>

commit 57e7ba04d422c3d41c8426380303ec9b7533ded9 upstream.

security_inode_getsecurity() provides the text string value of a security attribute. It does not provide a "secctx".
The code in xattr_getsecurity() that calls security_inode_getsecurity() and then calls security_release_secctx() happened to work because SElinux and Smack treat the attribute and the secctx the same way. It fails for cap_inode_getsecurity(), because that module has no secctx that ever needs releasing. It turns out that Smack is the one that's doing things wrong by not allocating memory when instructed to do so by the "alloc" parameter.

The fix is simple enough. Change the security_release_secctx() to kfree() because it isn't a secctx being returned by security_inode_getsecurity(). Change Smack to allocate the string when told to do so.

Note: this also fixes memory leaks for LSMs which implement inode_getsecurity but not release_secctx, such as capabilities.

---
 fs/xattr.c                 |    2 -
 security/smack/smack_lsm.c |   59 ++++++++++++++++++++-------------------------
 2 files changed, 28 insertions(+), 33 deletions(-)
fs/xattr.c +1 -1
@@ -249,7 +249,7 @@ xattr_getsecurity(struct inode *inode, c
 	}
 	memcpy(value, buffer, len);
 out:
-	security_release_secctx(buffer, len);
+	kfree(buffer);
 out_noalloc:
 	return len;
 }
security/smack/smack_lsm.c +27 -32

77 lines not on this page · raw message

author maintainer
#42 lore raw

PATCH 43/105 ALSA: compress: Remove unused variable

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Guneshwor Singh <[email protected]>

commit a931b9ce93841a5b66b709ba5a244276e345e63b upstream.

Commit 04c5d5a430fc ("ALSA: compress: Embed struct device") removed the statement that used 'str' but didn't remove the variable itself. So remove it.

[Adding stable to Cc since pr_debug() may refer to the uninitialized
buffer -- tiwai]

Fixes 04c5d5a430fc ("ALSA: compress: Embed struct device")
---
 sound/core/compress_offload.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
sound/core/compress_offload.c +1 -2
@@ -948,14 +948,13 @@ static const struct file_operations snd_
 static int snd_compress_dev_register(struct snd_device *device)
 {
 	int ret = -EINVAL;
-	char str[16];
 	struct snd_compr *compr;
 
 	if (snd_BUG_ON(!device || !device->device_data))
 		return -EBADFD;
 	compr = device->device_data;
 
-	pr_debug("reg %s for device %s, direction %d\n", str, compr->name,
+	pr_debug("reg device %s, direction %d\n", compr->name,
 			compr->direction);
 	/* register compressed device */
 	ret = snd_register_device(SNDRV_DEVICE_TYPE_COMPRESS,
author maintainer
#43 lore raw

PATCH 44/105 Revert "ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members"

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Takashi Sakamoto <[email protected]>

commit 51db452df07bb4c5754b73789253ba21681d9dc2 upstream.

This reverts commit 275353bb684e to fix a regression which can abort 'alsactl' program in alsa-utils due to assertion in alsa-lib.

alsactl: control.c:2513: snd_ctl_elem_value_get_integer: Assertion `idx < sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' failed.

alsactl: control.c:2976: snd_ctl_elem_value_get_integer: Assertion `idx < ARRAY_SIZE(obj->value.integer.value)' failed.

This commit is a band-aid. In a point of usage of ALSA control interface, the drivers still bring an issue that they prevent userspace applications to have a consistent way to parse each levels of the dimension information via ALSA control interface.

Let me investigate this issue. Current implementation of the drivers have three control element sets with dimension information:
* 'Monitor Mixer Volume' (type: integer)
* 'VMixer Volume' (type: integer)
* 'VU-meters' (type: boolean)

Although the number of elements named as 'Monitor Mixer Volume' differs depending on drivers in this group, it can be calculated by macros defined by each driver (= (BX_NUM - BX_ANALOG_IN) * BX_ANALOG_IN). Each of the elements has one member for value and has dimension information with 2 levels (= BX_ANALOG_IN * (BX_NUM - BX_ANALOG_IN)). For these elements, userspace applications are expected to handle the dimension information so that all of the elements construct a matrix where the number of rows and columns are represented by the dimension information.

The same way is applied to elements named as 'VMixer Volume'. The number of these elements can also be calculated by macros defined by each drivers (= PX_ANALOG_IN * BX_ANALOG_IN). Each of the element has one member for value and has dimension information with 2 levels (= BX_ANALOG_IN * PX_ANALOG_IN). All of the elements construct a matrix with the dimension information.

An element named as 'VU-meters' gets a different way in a point of dimension information. The element includes 96 members for value. The element has dimension information with 3 levels (= 3 or 2 * 16 * 2). For this element, userspace applications are expected to handle the dimension information so that all of the members for value construct a matrix where the number of rows and columns are represented by the dimension information. This is different from the way for the former.

As a summary, the drivers were not designed to produce a consistent way to parse the dimension information. This makes it hard for general userspace applications such as amixer to parse the information by a consistent way, and actually no userspace applications except for 'echomixer' utilize the dimension information. Additionally, no drivers excluding this group use the information.

The reverted commit was written based on the latter way. A commit 860c1994a70a ('ALSA: control: add dimension validator for userspace elements') is written based on the latter way, too. The patch should be reconsider too in the same time to re-define a consistent way to parse the dimension information.

Fixes 275353bb684e ('ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members')
---
 sound/pci/echoaudio/echoaudio.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
sound/pci/echoaudio/echoaudio.c +3 -3
@@ -1272,11 +1272,11 @@ static int snd_echo_mixer_info(struct sn
 
 	chip = snd_kcontrol_chip(kcontrol);
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+	uinfo->count = 1;
 	uinfo->value.integer.min = ECHOGAIN_MINOUT;
 	uinfo->value.integer.max = ECHOGAIN_MAXOUT;
 	uinfo->dimen.d[0] = num_busses_out(chip);
 	uinfo->dimen.d[1] = num_busses_in(chip);
-	uinfo->count = uinfo->dimen.d[0] * uinfo->dimen.d[1];
 	return 0;
 }
 
@@ -1344,11 +1344,11 @@ static int snd_echo_vmixer_info(struct s
 
 	chip = snd_kcontrol_chip(kcontrol);
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+	uinfo->count = 1;
 	uinfo->value.integer.min = ECHOGAIN_MINOUT;
 	uinfo->value.integer.max = ECHOGAIN_MAXOUT;
 	uinfo->dimen.d[0] = num_busses_out(chip);
 	uinfo->dimen.d[1] = num_pipes_out(chip);
-	uinfo->count = uinfo->dimen.d[0] * uinfo->dimen.d[1];
 	return 0;
 }
 
@@ -1728,6 +1728,7 @@ static int snd_echo_vumeters_info(struct
 				  struct snd_ctl_elem_info *uinfo)
 {
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+	uinfo->count = 96;
 	uinfo->value.integer.min = ECHOGAIN_MINOUT;
 	uinfo->value.integer.max = 0;
 #ifdef ECHOCARD_HAS_VMIXER
@@ -1737,7 +1738,6 @@ static int snd_echo_vumeters_info(struct
 #endif
 	uinfo->dimen.d[1] = 16;	/* 16 channels */
 	uinfo->dimen.d[2] = 2;	/* 0=level, 1=peak */
-	uinfo->count = uinfo->dimen.d[0] * uinfo->dimen.d[1] * uinfo->dimen.d[2];
 	return 0;
 }
 
author maintainer
#44 lore raw

PATCH 45/105 ALSA: usx2y: Suppress kernel warning at page allocation failures

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Takashi Iwai <[email protected]>

commit 7682e399485fe19622b6fd82510b1f4551e48a25 upstream.

The usx2y driver allocates the stream read/write buffers in continuous pages depending on the stream setup, and this may spew the kernel warning messages with a stack trace like:

  WARNING: CPU: 1 PID: 1846 at mm/page_alloc.c:3883
  __alloc_pages_slowpath+0x1ef2/0x2d70
  Modules linked in:
  CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
  ....

It may confuse user as if it were any serious error, although this is no fatal error and the driver handles the error case gracefully. Since the driver has already some sanity check of the given size (128 and 256 pages), it can't pass any crazy value. So it's merely page fragmentation.

This patch adds __GFP_NOWARN to each caller for suppressing such kernel warnings. The original issue was spotted by syzkaller.

---
 sound/usb/usx2y/usb_stream.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
sound/usb/usx2y/usb_stream.c +4 -2
@@ -191,7 +191,8 @@ struct usb_stream *usb_stream_new(struct
 	}
 
 	pg = get_order(read_size);
-	sk->s = (void *) __get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO, pg);
+	sk->s = (void *) __get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|
+					  __GFP_NOWARN, pg);
 	if (!sk->s) {
 		snd_printk(KERN_WARNING "couldn't __get_free_pages()\n");
 		goto out;
@@ -211,7 +212,8 @@ struct usb_stream *usb_stream_new(struct
 	pg = get_order(write_size);
 
 	sk->write_page =
-		(void *)__get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO, pg);
+		(void *)__get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|
+					 __GFP_NOWARN, pg);
 	if (!sk->write_page) {
 		snd_printk(KERN_WARNING "couldn't __get_free_pages()\n");
 		usb_stream_free(sk);
author maintainer
#45 lore raw

PATCH 46/105 mlxsw: spectrum: Prevent mirred-related crash on removal

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yuval Mintz <[email protected]>

[ Upstream commit 6399ebcccffa12e65bc15eda039d37673264ebce ]

When removing the offloading of mirred actions under matchall classifiers, mlxsw would find the destination port associated with the offloaded action and utilize it for undoing the configuration.

Depending on the order by which ports are removed, it's possible that the destination port would get removed before the source port. In such a scenario, when actions would be flushed for the source port mlxsw would perform an illegal dereference as the destination port is no longer listed.

Since the only item necessary for undoing the configuration on the destination side is the port-id and that in turn is already maintained by mlxsw on the source-port, simply stop trying to access the destination port and use the port-id directly instead.

Fixes 763b4b70af ("mlxsw: spectrum: Add support in matchall mirror TC offloading")
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum.c +10 -10
@@ -249,15 +249,14 @@ static void mlxsw_sp_span_entry_destroy(
 }
 
 static struct mlxsw_sp_span_entry *
-mlxsw_sp_span_entry_find(struct mlxsw_sp_port *port)
+mlxsw_sp_span_entry_find(struct mlxsw_sp *mlxsw_sp, u8 local_port)
 {
-	struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
 	int i;
 
 	for (i = 0; i < mlxsw_sp->span.entries_count; i++) {
 		struct mlxsw_sp_span_entry *curr = &mlxsw_sp->span.entries[i];
 
-		if (curr->used && curr->local_port == port->local_port)
+		if (curr->used && curr->local_port == local_port)
 			return curr;
 	}
 	return NULL;
@@ -268,7 +267,8 @@ static struct mlxsw_sp_span_entry
 {
 	struct mlxsw_sp_span_entry *span_entry;
 
-	span_entry = mlxsw_sp_span_entry_find(port);
+	span_entry = mlxsw_sp_span_entry_find(port->mlxsw_sp,
+					      port->local_port);
 	if (span_entry) {
 		/* Already exists, just take a reference */
 		span_entry->ref_count++;
@@ -453,12 +453,13 @@ err_port_bind:
 }
 
 static void mlxsw_sp_span_mirror_remove(struct mlxsw_sp_port *from,
-					struct mlxsw_sp_port *to,
+					u8 destination_port,
 					enum mlxsw_sp_span_type type)
 {
 	struct mlxsw_sp_span_entry *span_entry;
 
-	span_entry = mlxsw_sp_span_entry_find(to);
+	span_entry = mlxsw_sp_span_entry_find(from->mlxsw_sp,
+					      destination_port);
 	if (!span_entry) {
 		netdev_err(from->dev, "no span entry found\n");
 		return;
@@ -1255,10 +1256,8 @@ static int mlxsw_sp_port_add_cls_matchal
 static void mlxsw_sp_port_del_cls_matchall(struct mlxsw_sp_port *mlxsw_sp_port,
 					   struct tc_cls_matchall_offload *cls)
 {
-	struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
 	struct mlxsw_sp_port_mall_tc_entry *mall_tc_entry;
 	enum mlxsw_sp_span_type span_type;
-	struct mlxsw_sp_port *to_port;
 
 	mall_tc_entry = mlxsw_sp_port_mirror_entry_find(mlxsw_sp_port,
 							cls->cookie);
@@ -1269,11 +1268,12 @@ static void mlxsw_sp_port_del_cls_matcha
 
 	switch (mall_tc_entry->type) {
 	case MLXSW_SP_PORT_MALL_MIRROR:
-		to_port = mlxsw_sp->ports[mall_tc_entry->mirror.to_local_port];
 		span_type = mall_tc_entry->mirror.ingress ?
 				MLXSW_SP_SPAN_INGRESS : MLXSW_SP_SPAN_EGRESS;
 
-		mlxsw_sp_span_mirror_remove(mlxsw_sp_port, to_port, span_type);
+		mlxsw_sp_span_mirror_remove(mlxsw_sp_port,
+					    mall_tc_entry->mirror.to_local_port,
+					    span_type);
 		break;
 	default:
 		WARN_ON(1);
author maintainer
#46 lore raw

PATCH 47/105 net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jiri Pirko <[email protected]>

[ Upstream commit 255cd50f207ae8ec7b22663246c833407744e634 ]

Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed freeing in call_rcu, which changed already existing hard-to-hit race condition into 100% hit:

[  598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[  598.607782] IP: tcf_action_destroy+0xc0/0x140

Or:

[   40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[   40.862840] IP: tcf_generic_walker+0x534/0x820

Fix this by storing the ops and use them directly for module_put call.

Fixes a85a970af265 ("net_sched: move tc_action into tcf_common")
---
 net/sched/act_api.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
net/sched/act_api.c +4 -2
@@ -141,7 +141,7 @@ static int tcf_del_walker(struct tcf_has
 		hlist_for_each_entry_safe(p, n, head, tcfa_head) {
 			ret = __tcf_hash_release(p, false, true);
 			if (ret == ACT_P_DELETED) {
-				module_put(p->ops->owner);
+				module_put(ops->owner);
 				n_i++;
 			} else if (ret < 0)
 				goto nla_put_failure;
@@ -450,13 +450,15 @@ EXPORT_SYMBOL(tcf_action_exec);
 
 int tcf_action_destroy(struct list_head *actions, int bind)
 {
+	const struct tc_action_ops *ops;
 	struct tc_action *a, *tmp;
 	int ret = 0;
 
 	list_for_each_entry_safe(a, tmp, actions, list) {
+		ops = a->ops;
 		ret = __tcf_hash_release(a, bind, true);
 		if (ret == ACT_P_DELETED)
-			module_put(a->ops->owner);
+			module_put(ops->owner);
 		else if (ret < 0)
 			return ret;
 	}
author maintainer
#47 lore raw

PATCH 48/105 sctp: potential read out of bounds in sctp_ulpevent_type_enabled()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit fa5f7b51fc3080c2b195fa87c7eca7c05e56f673 ]

This code causes a static checker warning because Smatch doesn't trust anything that comes from skb->data. I've reviewed this code and I do think skb->data can be controlled by the user here.

The sctp_event_subscribe struct has 13 __u8 fields and we want to see if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range. We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read either before the start of the struct or after the end.

This is a very old bug and it's surprising that it would go undetected for so long but my theory is that it just doesn't have a big impact so it would be hard to notice.

---
 include/net/sctp/ulpevent.h |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
include/net/sctp/ulpevent.h +5 -1
@@ -141,8 +141,12 @@ __u16 sctp_ulpevent_get_notification_typ
 static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
 					     struct sctp_event_subscribe *mask)
 {
+	int offset = sn_type - SCTP_SN_TYPE_BASE;
 	char *amask = (char *) mask;
-	return amask[sn_type - SCTP_SN_TYPE_BASE];
+
+	if (offset >= sizeof(struct sctp_event_subscribe))
+		return 0;
+	return amask[offset];
 }
 
 /* Given an event subscription, is this event enabled? */
author maintainer
#48 lore raw

PATCH 49/105 tcp: update skb->skb_mstamp more carefully

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 8c72c65b426b47b3c166a8fef0d8927fe5e8a28d ]

liujian reported a problem in TCP_USER_TIMEOUT processing with a patch in tcp_probe_timer() :

      https://www.spinics.net/lists/netdev/msg454496.html

After investigations, the root cause of the problem is that we update skb->skb_mstamp of skbs in write queue, even if the attempt to send a clone or copy of it failed. One reason being a routing problem.

This patch prevents this, solving liujian issue.

It also removes a potential RTT miscalculation, since __tcp_retransmit_skb() is not OR-ing TCP_SKB_CB(skb)->sacked with TCPCB_EVER_RETRANS if a failure happens, but skb->skb_mstamp has been changed.

A future ACK would then lead to a very small RTT sample and min_rtt would then be lowered to this too small value.

Tested:

# cat user_timeout.pkt
--local_ip=192.168.102.64
    0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3

+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0

+0 ifconfig tun0 192.168.102.64/16; ip ro add 192.0.2.1 dev tun0

+0 < S 0:0(0) win 0 <mss 1460>
+0 > S. 0:0(0) ack 1 <mss 1460>

+.1 < . 1:1(0) ack 1 win 65530
+0 accept(3, ..., ...) = 4

+0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0 +0 write(4, ..., 24) = 24
+0 > P. 1:25(24) ack 1 win 29200
+.1 < . 1:1(0) ack 25 win 65530

//change the ipaddress
+1 ifconfig tun0 192.168.0.10/16

+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24

+0 ifconfig tun0 192.168.102.64/16
+0 < . 1:2(1) ack 25 win 65530
+0 ifconfig tun0 192.168.0.10/16

+3 write(4, ..., 24) = -1

# ./packetdrill user_timeout.pkt
---
 net/ipv4/tcp_output.c |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)
net/ipv4/tcp_output.c +12 -7
@@ -914,6 +914,7 @@ static int tcp_transmit_skb(struct sock
 	struct tcp_skb_cb *tcb;
 	struct tcp_out_options opts;
 	unsigned int tcp_options_size, tcp_header_size;
+	struct sk_buff *oskb = NULL;
 	struct tcp_md5sig_key *md5;
 	struct tcphdr *th;
 	int err;
@@ -922,11 +923,11 @@ static int tcp_transmit_skb(struct sock
 	tp = tcp_sk(sk);
 
 	if (clone_it) {
-		skb_mstamp_get(&skb->skb_mstamp);
 		TCP_SKB_CB(skb)->tx.in_flight = TCP_SKB_CB(skb)->end_seq
 			- tp->snd_una;
 		tcp_rate_skb_sent(sk, skb);
 
+		oskb = skb;
 		if (unlikely(skb_cloned(skb)))
 			skb = pskb_copy(skb, gfp_mask);
 		else
@@ -934,6 +935,7 @@ static int tcp_transmit_skb(struct sock
 		if (unlikely(!skb))
 			return -ENOBUFS;
 	}
+	skb_mstamp_get(&skb->skb_mstamp);
 
 	inet = inet_sk(sk);
 	tcb = TCP_SKB_CB(skb);
@@ -1035,12 +1037,14 @@ static int tcp_transmit_skb(struct sock
 
 	err = icsk->icsk_af_ops->queue_xmit(sk, skb, &inet->cork.fl);
 
-	if (likely(err <= 0))
-		return err;
-
-	tcp_enter_cwr(sk);
+	if (unlikely(err > 0)) {
+		tcp_enter_cwr(sk);
+		err = net_xmit_eval(err);
+	}
+	if (!err && oskb)
+		skb_mstamp_get(&oskb->skb_mstamp);
 
-	return net_xmit_eval(err);
+	return err;
 }
 
 /* This routine just queues the buffer for sending.
@@ -2709,10 +2713,11 @@ int __tcp_retransmit_skb(struct sock *sk
 		     skb_headroom(skb) >= 0xFFFF)) {
 		struct sk_buff *nskb;
 
-		skb_mstamp_get(&skb->skb_mstamp);
 		nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
 		err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
 			     -ENOBUFS;
+		if (!err)
+			skb_mstamp_get(&skb->skb_mstamp);
 	} else {
 		err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
 	}
author maintainer
#49 lore raw

PATCH 50/105 bpf/verifier: reject BPF_ALU64|BPF_END

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Edward Cree <[email protected]>

[ Upstream commit e67b8a685c7c984e834e3181ef4619cd7025a136 ]

Neither ___bpf_prog_run nor the JITs accept it. Also adds a new test case.

---
 kernel/bpf/verifier.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/bpf/verifier.c +2 -1
@@ -1720,7 +1720,8 @@ static int check_alu_op(struct bpf_verif
 			}
 		} else {
 			if (insn->src_reg != BPF_REG_0 || insn->off != 0 ||
-			    (insn->imm != 16 && insn->imm != 32 && insn->imm != 64)) {
+			    (insn->imm != 16 && insn->imm != 32 && insn->imm != 64) ||
+			    BPF_CLASS(insn->code) == BPF_ALU64) {
 				verbose("BPF_END uses reserved fields\n");
 				return -EINVAL;
 			}
author maintainer
#50 lore raw

PATCH 51/105 tcp: fix data delivery rate

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>

[ Upstream commit fc22579917eb7e13433448a342f1cb1592920940 ]

Now skb->mstamp_skb is updated later, we also need to call tcp_rate_skb_sent() after the update is done.

Fixes 8c72c65b426b ("tcp: update skb->skb_mstamp more carefully")
---
 net/ipv4/tcp_output.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
net/ipv4/tcp_output.c +3 -4
@@ -925,8 +925,6 @@ static int tcp_transmit_skb(struct sock
 	if (clone_it) {
 		TCP_SKB_CB(skb)->tx.in_flight = TCP_SKB_CB(skb)->end_seq
 			- tp->snd_una;
-		tcp_rate_skb_sent(sk, skb);
-
 		oskb = skb;
 		if (unlikely(skb_cloned(skb)))
 			skb = pskb_copy(skb, gfp_mask);
@@ -1041,9 +1039,10 @@ static int tcp_transmit_skb(struct sock
 		tcp_enter_cwr(sk);
 		err = net_xmit_eval(err);
 	}
-	if (!err && oskb)
+	if (!err && oskb) {
 		skb_mstamp_get(&oskb->skb_mstamp);
-
+		tcp_rate_skb_sent(sk, oskb);
+	}
 	return err;
 }
 
author maintainer
#51 lore raw

PATCH 52/105 udpv6: Fix the checksum computation when HW checksum does not apply

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Subash Abhinov Kasiviswanathan <[email protected]>

[ Upstream commit 63ecc3d9436f8012e49dc846d6cb0a85a3433517 ]

While trying an ESP transport mode encryption for UDPv6 packets of datagram size 1436 with MTU 1500, checksum error was observed in the secondary fragment.

This error occurs due to the UDP payload checksum being missed out when computing the full checksum for these packets in udp6_hwcsum_outgoing().

Fixes d39d938c8228 ("ipv6: Introduce udpv6_send_skb()")
---
 net/ipv6/udp.c |    1 +
 1 file changed, 1 insertion(+)
net/ipv6/udp.c +1 -0
@@ -915,6 +915,7 @@ static void udp6_hwcsum_outgoing(struct
 		 */
 		offset = skb_transport_offset(skb);
 		skb->csum = skb_checksum(skb, offset, skb->len - offset, 0);
+		csum = skb->csum;
 
 		skb->ip_summed = CHECKSUM_NONE;
 
author maintainer
#52 lore raw

PATCH 53/105 ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Xin Long <[email protected]>

[ Upstream commit 76cc0d3282d4b933fa144fa41fbc5318e0fdca24 ]

Now in ip6gre_header before packing the ipv6 header, it skb_push t->hlen which only includes encap_hlen + tun_hlen. It means greh and inner header would be over written by ipv6 stuff and ipv6h might have no chance to set up.

Jianlin found this issue when using remote any on ip6_gre, the packets he captured on gre dev are truncated:

22:50:26.210866 Out ethertype IPv6 (0x86dd), length 120: truncated-ip6 -\
8128 bytes missing!(flowlabel 0x92f40, hlim 0, next-header Options (0) \
payload length: 8192) ::1:2000:0 > ::1:0:86dd: HBH [trunc] ip-proto-128 \
8184

It should also skb_push ipv6hdr so that ipv6h points to the right position to set ipv6 stuff up.

This patch is to skb_push hlen + sizeof(*ipv6h) and also fix some indents in ip6gre_header.

Fixes c12b395a4664 ("gre: Support GRE over IPv6")
---
 net/ipv6/ip6_gre.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
net/ipv6/ip6_gre.c +11 -10
@@ -936,24 +936,25 @@ done:
 }
 
 static int ip6gre_header(struct sk_buff *skb, struct net_device *dev,
-			unsigned short type,
-			const void *daddr, const void *saddr, unsigned int len)
+			 unsigned short type, const void *daddr,
+			 const void *saddr, unsigned int len)
 {
 	struct ip6_tnl *t = netdev_priv(dev);
-	struct ipv6hdr *ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen);
-	__be16 *p = (__be16 *)(ipv6h+1);
+	struct ipv6hdr *ipv6h;
+	__be16 *p;
 
-	ip6_flow_hdr(ipv6h, 0,
-		     ip6_make_flowlabel(dev_net(dev), skb,
-					t->fl.u.ip6.flowlabel, true,
-					&t->fl.u.ip6));
+	ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen + sizeof(*ipv6h));
+	ip6_flow_hdr(ipv6h, 0, ip6_make_flowlabel(dev_net(dev), skb,
+						  t->fl.u.ip6.flowlabel,
+						  true, &t->fl.u.ip6));
 	ipv6h->hop_limit = t->parms.hop_limit;
 	ipv6h->nexthdr = NEXTHDR_GRE;
 	ipv6h->saddr = t->parms.laddr;
 	ipv6h->daddr = t->parms.raddr;
 
-	p[0]		= t->parms.o_flags;
-	p[1]		= htons(type);
+	p = (__be16 *)(ipv6h + 1);
+	p[0] = t->parms.o_flags;
+	p[1] = htons(type);
 
 	/*
 	 *	Set the source hardware address.
author maintainer
#53 lore raw

PATCH 54/105 net: phy: Fix mask value write on gmii2rgmii converter speed register

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Fahad Kunnathadi <[email protected]>

[ Upstream commit f2654a4781318dc7ab8d6cde66f1fa39eab980a9 ]

To clear Speed Selection in MDIO control register(0x10), ie, clear bits 6 and 13 to zero while keeping other bits same. Before AND operation,The Mask value has to be perform with bitwise NOT operation (ie, ~ operator)

This patch clears current speed selection before writing the new speed settings to gmii2rgmii converter

Fixes f411a6160bd4 ("net: phy: Add gmiitorgmii converter support")
---
 drivers/net/phy/xilinx_gmii2rgmii.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/xilinx_gmii2rgmii.c +1 -1
@@ -44,7 +44,7 @@ static int xgmiitorgmii_read_status(stru
 	priv->phy_drv->read_status(phydev);
 
 	val = mdiobus_read(phydev->mdio.bus, priv->addr, XILINX_GMII2RGMII_REG);
-	val &= XILINX_GMII2RGMII_SPEED_MASK;
+	val &= ~XILINX_GMII2RGMII_SPEED_MASK;
 
 	if (phydev->speed == SPEED_1000)
 		val |= BMCR_SPEED1000;
author maintainer
#54 lore raw

PATCH 55/105 ip6_tunnel: do not allow loading ip6_tunnel if ipv6 is disabled in cmdline

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Xin Long <[email protected]>

[ Upstream commit 8c22dab03ad072e45060c299c70d02a4f6fc4aab ]

If ipv6 has been disabled from cmdline since kernel started, it makes no sense to allow users to create any ip6 tunnel. Otherwise, it could some potential problem.

Jianlin found a kernel crash caused by this in ip6_gre when he set ipv6.disable=1 in grub:

[  209.588865] Unable to handle kernel paging request for data at address 0x00000080
[  209.588872] Faulting instruction address: 0xc000000000a3aa6c
[  209.588879] Oops: Kernel access of bad area, sig: 11 [#1]
[  209.589062] NIP [c000000000a3aa6c] fib_rules_lookup+0x4c/0x260
[  209.589071] LR [c000000000b9ad90] fib6_rule_lookup+0x50/0xb0
[  209.589076] Call Trace:
[  209.589097] fib6_rule_lookup+0x50/0xb0
[  209.589106] rt6_lookup+0xc4/0x110
[  209.589116] ip6gre_tnl_link_config+0x214/0x2f0 [ip6_gre]
[  209.589125] ip6gre_newlink+0x138/0x3a0 [ip6_gre]
[  209.589134] rtnl_newlink+0x798/0xb80
[  209.589142] rtnetlink_rcv_msg+0xec/0x390
[  209.589151] netlink_rcv_skb+0x138/0x150
[  209.589159] rtnetlink_rcv+0x48/0x70
[  209.589169] netlink_unicast+0x538/0x640
[  209.589175] netlink_sendmsg+0x40c/0x480
[  209.589184] ___sys_sendmsg+0x384/0x4e0
[  209.589194] SyS_sendmsg+0xd4/0x140
[  209.589201] SyS_socketcall+0x3e0/0x4f0
[  209.589209] system_call+0x38/0xe0

This patch is to return -EOPNOTSUPP in ip6_tunnel_init if ipv6 has been disabled from cmdline.

---
 net/ipv6/ip6_tunnel.c |    3 +++
 1 file changed, 3 insertions(+)
net/ipv6/ip6_tunnel.c +3 -0
@@ -2231,6 +2231,9 @@ static int __init ip6_tunnel_init(void)
 {
 	int  err;
 
+	if (!ipv6_mod_enabled())
+		return -EOPNOTSUPP;
+
 	err = register_pernet_device(&ip6_tnl_net_ops);
 	if (err < 0)
 		goto out_pernet;
author maintainer
#55 lore raw

PATCH 56/105 net/sched: cls_matchall: fix crash when used with classful qdisc

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Davide Caratti <[email protected]>

[ Upstream commit 3ff4cbec87da48b0ec1f7b6196607b034de0c680 ]

this script, edited from Linux Advanced Routing and Traffic Control guide

tc q a dev en0 root handle 1: htb default a
tc c a dev en0 parent 1: classid 1:1 htb rate 6mbit burst 15k tc c a dev en0 parent 1:1 classid 1:a htb rate 5mbit ceil 6mbit burst 15k tc c a dev en0 parent 1:1 classid 1:b htb rate 1mbit ceil 6mbit burst 15k tc f a dev en0 parent 1:0 prio 1 $clsname $clsargs classid 1:b ping $address -c1
tc -s c s dev en0

classifies traffic to 1:b or 1:a, depending on whether the packet matches or not the pattern $clsargs of filter $clsname. However, when $clsname is 'matchall', a systematic crash can be observed in htb_classify(). HTB and classful qdiscs don't assign initial value to struct tcf_result, but then they expect it to contain valid values after filters have been run. Thus, current 'matchall' ignores the TCA_MATCHALL_CLASSID attribute, configured by user, and makes HTB (and classful qdiscs) dereference random pointers.

By assigning head->res to *res in mall_classify(), before the actions are invoked, we fix this crash and enable TCA_MATCHALL_CLASSID functionality, that had no effect on 'matchall' classifier since its first introduction.

---
 net/sched/cls_matchall.c |    1 +
 1 file changed, 1 insertion(+)
net/sched/cls_matchall.c +1 -0
@@ -32,6 +32,7 @@ static int mall_classify(struct sk_buff
 	if (tc_skip_sw(head->flags))
 		return -1;
 
+	*res = head->res;
 	return tcf_exts_exec(skb, &head->exts, res);
 }
 
author maintainer
#56 lore raw

PATCH 57/105 tcp: fastopen: fix on syn-data transmit failure

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>

[ Upstream commit b5b7db8d680464b1d631fd016f5e093419f0bfd9 ]

Our recent change exposed a bug in TCP Fastopen Client that syzkaller found right away [1]

When we prepare skb with SYN+DATA, we attempt to transmit it, and we update socket state as if the transmit was a success.

In socket RTX queue we have two skbs, one with the SYN alone, and a second one containing the DATA.

When (malicious) ACK comes in, we now complain that second one had no skb_mstamp.

The proper fix is to make sure that if the transmit failed, we do not pretend we sent the DATA skb, and make it our send_head.

When 3WHS completes, we can now send the DATA right away, without having to wait for a timeout.

[1]

WARNING: CPU: 0 PID: 100189 at net/ipv4/tcp_input.c:3117 tcp_clean_rtx_queue+0x2057/0x2ab0 net/ipv4/tcp_input.c:3117()

WARN_ON_ONCE(last_ackt == 0);

Modules linked in:
CPU: 0 PID: 100189 Comm: syz-executor1 Not tainted
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 0000000000000000 ffff8800b35cb1d8 ffffffff81cad00d 0000000000000000
 ffffffff828a4347 ffff88009f86c080 ffffffff8316eb20 0000000000000d7f
 ffff8800b35cb220 ffffffff812c33c2 ffff8800baad2440 00000009d46575c0
Call Trace:
 [<ffffffff81cad00d>] __dump_stack
 [<ffffffff81cad00d>] dump_stack+0xc1/0x124
 [<ffffffff812c33c2>] warn_slowpath_common+0xe2/0x150
 [<ffffffff812c361e>] warn_slowpath_null+0x2e/0x40
 [<ffffffff828a4347>] tcp_clean_rtx_queue+0x2057/0x2ab0 n
 [<ffffffff828ae6fd>] tcp_ack+0x151d/0x3930
 [<ffffffff828baa09>] tcp_rcv_state_process+0x1c69/0x4fd0
 [<ffffffff828efb7f>] tcp_v4_do_rcv+0x54f/0x7c0
 [<ffffffff8258aacb>] sk_backlog_rcv
 [<ffffffff8258aacb>] __release_sock+0x12b/0x3a0
 [<ffffffff8258ad9e>] release_sock+0x5e/0x1c0
 [<ffffffff8294a785>] inet_wait_for_connect
 [<ffffffff8294a785>] __inet_stream_connect+0x545/0xc50
 [<ffffffff82886f08>] tcp_sendmsg_fastopen
 [<ffffffff82886f08>] tcp_sendmsg+0x2298/0x35a0
 [<ffffffff82952515>] inet_sendmsg+0xe5/0x520
 [<ffffffff8257152f>] sock_sendmsg_nosec
 [<ffffffff8257152f>] sock_sendmsg+0xcf/0x110
Fixes 8c72c65b426b ("tcp: update skb->skb_mstamp more carefully")
Fixes 783237e8daf1 ("net-tcp: Fast Open client - sending SYN-data")
Cc Neal Cardwell <[email protected]>
Cc Yuchung Cheng <[email protected]>
---
 net/ipv4/tcp_output.c |    9 +++++++++
 1 file changed, 9 insertions(+)
net/ipv4/tcp_output.c +9 -0
@@ -3329,6 +3329,10 @@ static int tcp_send_syn_data(struct sock
 		goto done;
 	}
 
+	/* data was not sent, this is our new send_head */
+	sk->sk_send_head = syn_data;
+	tp->packets_out -= tcp_skb_pcount(syn_data);
+
 fallback:
 	/* Send a regular SYN with Fast Open cookie request option */
 	if (fo->cookie.len > 0)
@@ -3378,6 +3382,11 @@ int tcp_connect(struct sock *sk)
 	 */
 	tp->snd_nxt = tp->write_seq;
 	tp->pushed_seq = tp->write_seq;
+	buff = tcp_send_head(sk);
+	if (unlikely(buff)) {
+		tp->snd_nxt	= TCP_SKB_CB(buff)->seq;
+		tp->pushed_seq	= TCP_SKB_CB(buff)->seq;
+	}
 	TCP_INC_STATS(sock_net(sk), TCP_MIB_ACTIVEOPENS);
 
 	/* Timer for repeating the SYN until an answer. */
author maintainer
#57 lore raw

PATCH 58/105 net: emac: Fix napi poll list corruption

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christian Lamparter <[email protected]>

[ Upstream commit f55956065ec94e3e9371463d693a1029c4cc3007 ]

This patch is pretty much a carbon copy of
commit 3079c652141f ("caif: Fix napi poll list corruption") with "caif" replaced by "emac".

The commit d75b1ade567f ("net: less interrupt masking in NAPI") breaks emac.

It is now required that if the entire budget is consumed when poll returns, the napi poll_list must remain empty. However, like some other drivers emac tries to do a last-ditch check and if there is more work it will call napi_reschedule and then immediately process some of this new work. Should the entire budget be consumed while processing such new work then we will violate the new caller contract.

This patch fixes this by not touching any work when we reschedule in emac.

---
 drivers/net/ethernet/ibm/emac/mal.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/ethernet/ibm/emac/mal.c +1 -2
@@ -402,7 +402,7 @@ static int mal_poll(struct napi_struct *
 	unsigned long flags;
 
 	MAL_DBG2(mal, "poll(%d)" NL, budget);
- again:
+
 	/* Process TX skbs */
 	list_for_each(l, &mal->poll_list) {
 		struct mal_commac *mc =
@@ -451,7 +451,6 @@ static int mal_poll(struct napi_struct *
 			spin_lock_irqsave(&mal->lock, flags);
 			mal_disable_eob_irq(mal);
 			spin_unlock_irqrestore(&mal->lock, flags);
-			goto again;
 		}
 		mc->ops->poll_tx(mc->dev);
 	}
author maintainer
#58 lore raw

PATCH 59/105 packet: hold bind lock when rebinding to fanout hook

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Willem de Bruijn <[email protected]>

[ Upstream commit 008ba2a13f2d04c947adc536d19debb8fe66f110 ]

Packet socket bind operations must hold the po->bind_lock. This keeps po->running consistent with whether the socket is actually on a ptype list to receive packets.

fanout_add unbinds a socket and its packet_rcv/tpacket_rcv call, then binds the fanout object to receive through packet_rcv_fanout.

Make it hold the po->bind_lock when testing po->running and rebinding. Else, it can race with other rebind operations, such as that in packet_set_ring from packet_rcv to tpacket_rcv. Concurrent updates can result in a socket being added to a fanout group twice, causing use-after-free KASAN bug reports, among others.

Reported independently by both trinity and syzkaller. Verified that the syzkaller reproducer passes after this patch.

Fixes dc99f600698d ("packet: Add fanout support.")
---
 net/packet/af_packet.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)
net/packet/af_packet.c +11 -5
@@ -1648,10 +1648,6 @@ static int fanout_add(struct sock *sk, u
 
 	mutex_lock(&fanout_mutex);
 
-	err = -EINVAL;
-	if (!po->running)
-		goto out;
-
 	err = -EALREADY;
 	if (po->fanout)
 		goto out;
@@ -1700,7 +1696,10 @@ static int fanout_add(struct sock *sk, u
 		list_add(&match->list, &fanout_list);
 	}
 	err = -EINVAL;
-	if (match->type == type &&
+
+	spin_lock(&po->bind_lock);
+	if (po->running &&
+	    match->type == type &&
 	    match->prot_hook.type == po->prot_hook.type &&
 	    match->prot_hook.dev == po->prot_hook.dev) {
 		err = -ENOSPC;
@@ -1712,6 +1711,13 @@ static int fanout_add(struct sock *sk, u
 			err = 0;
 		}
 	}
+	spin_unlock(&po->bind_lock);
+
+	if (err && !refcount_read(&match->sk_ref)) {
+		list_del(&match->list);
+		kfree(match);
+	}
+
 out:
 	if (err && rollover) {
 		kfree(rollover);
author maintainer
#59 lore raw

PATCH 60/105 bpf: one perf event close wont free bpf program attached by another perf event

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Yonghong Song <[email protected]>

[ Upstream commit ec9dd352d591f0c90402ec67a317c1ed4fb2e638 ]

This patch fixes a bug exhibited by the following scenario:
1. fd1 = perf_event_open with attr.config = ID1
2. attach bpf program prog1 to fd1
3. fd2 = perf_event_open with attr.config = ID1
<this will be successful>
4. user program closes fd2 and prog1 is detached from the tracepoint.
5. user program with fd1 does not work properly as tracepoint no output any more.

The issue happens at step 4. Multiple perf_event_open can be called successfully, but only one bpf prog pointer in the tp_event. In the current logic, any fd release for the same tp_event will free the tp_event->prog.

The fix is to free tp_event->prog only when the closing fd corresponds to the one which registered the program.

---
 include/linux/trace_events.h |    1 +
 kernel/events/core.c         |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
include/linux/trace_events.h +1 -0
@@ -273,6 +273,7 @@ struct trace_event_call {
 	int				perf_refcount;
 	struct hlist_head __percpu	*perf_events;
 	struct bpf_prog			*prog;
+	struct perf_event		*bpf_prog_owner;
 
 	int	(*perf_perm)(struct trace_event_call *,
 			     struct perf_event *);
kernel/events/core.c +2 -1
@@ -7871,6 +7871,7 @@ static int perf_event_set_bpf_prog(struc
 		}
 	}
 	event->tp_event->prog = prog;
+	event->tp_event->bpf_prog_owner = event;
 
 	return 0;
 }
@@ -7885,7 +7886,7 @@ static void perf_event_free_bpf_prog(str
 		return;
 
 	prog = event->tp_event->prog;
-	if (prog) {
+	if (prog && event->tp_event->bpf_prog_owner == event) {
 		event->tp_event->prog = NULL;
 		bpf_prog_put(prog);
 	}
author maintainer
#60 lore raw

PATCH 61/105 isdn/i4l: fetch the ppp_write buffer in one shot

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Meng Xu <[email protected]>

[ Upstream commit 02388bf87f72e1d47174cd8f81c34443920eb5a0 ]

In isdn_ppp_write(), the header (i.e., protobuf) of the buffer is fetched twice from userspace. The first fetch is used to peek at the protocol of the message and reset the huptimer if necessary; while the second fetch copies in the whole buffer. However, given that buf resides in userspace memory, a user process can race to change its memory content across fetches. By doing so, we can either avoid resetting the huptimer for any type of packets (by first setting proto to PPP_LCP and later change to the actual type) or force resetting the huptimer for LCP packets.

This patch changes this double-fetch behavior into two single fetches decided by condition (lp->isdn_device < 0 || lp->isdn_channel <0). A more detailed discussion can be found at
https://marc.info/?l=linux-kernel&m=150586376926123&w=2

---
 drivers/isdn/i4l/isdn_ppp.c |   37 +++++++++++++++++++++++++------------
 1 file changed, 25 insertions(+), 12 deletions(-)
drivers/isdn/i4l/isdn_ppp.c +25 -12
@@ -828,7 +828,6 @@ isdn_ppp_write(int min, struct file *fil
 	isdn_net_local *lp;
 	struct ippp_struct *is;
 	int proto;
-	unsigned char protobuf[4];
 
 	is = file->private_data;
 
@@ -842,24 +841,28 @@ isdn_ppp_write(int min, struct file *fil
 	if (!lp)
 		printk(KERN_DEBUG "isdn_ppp_write: lp == NULL\n");
 	else {
-		/*
-		 * Don't reset huptimer for
-		 * LCP packets. (Echo requests).
-		 */
-		if (copy_from_user(protobuf, buf, 4))
-			return -EFAULT;
-		proto = PPP_PROTOCOL(protobuf);
-		if (proto != PPP_LCP)
-			lp->huptimer = 0;
+		if (lp->isdn_device < 0 || lp->isdn_channel < 0) {
+			unsigned char protobuf[4];
+			/*
+			 * Don't reset huptimer for
+			 * LCP packets. (Echo requests).
+			 */
+			if (copy_from_user(protobuf, buf, 4))
+				return -EFAULT;
+
+			proto = PPP_PROTOCOL(protobuf);
+			if (proto != PPP_LCP)
+				lp->huptimer = 0;
 
-		if (lp->isdn_device < 0 || lp->isdn_channel < 0)
 			return 0;
+		}
 
 		if ((dev->drv[lp->isdn_device]->flags & DRV_FLAG_RUNNING) &&
 		    lp->dialstate == 0 &&
 		    (lp->flags & ISDN_NET_CONNECTED)) {
 			unsigned short hl;
 			struct sk_buff *skb;
+			unsigned char *cpy_buf;
 			/*
 			 * we need to reserve enough space in front of
 			 * sk_buff. old call to dev_alloc_skb only reserved
@@ -872,11 +875,21 @@ isdn_ppp_write(int min, struct file *fil
 				return count;
 			}
 			skb_reserve(skb, hl);
-			if (copy_from_user(skb_put(skb, count), buf, count))
+			cpy_buf = skb_put(skb, count);
+			if (copy_from_user(cpy_buf, buf, count))
 			{
 				kfree_skb(skb);
 				return -EFAULT;
 			}
+
+			/*
+			 * Don't reset huptimer for
+			 * LCP packets. (Echo requests).
+			 */
+			proto = PPP_PROTOCOL(cpy_buf);
+			if (proto != PPP_LCP)
+				lp->huptimer = 0;
+
 			if (is->debug & 0x40) {
 				printk(KERN_DEBUG "ppp xmit: len %d\n", (int) skb->len);
 				isdn_ppp_frame_log("xmit", skb->data, skb->len, 32, is->unit, lp->ppp_slot);
author maintainer
#61 lore raw

PATCH 62/105 net_sched: always reset qdisc backlog in qdisc_reset()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Konstantin Khlebnikov <[email protected]>

[ Upstream commit c8e1812960eeae42e2183154927028511c4bc566 ]

SKB stored in qdisc->gso_skb also counted into backlog.

Some qdiscs don't reset backlog to zero in ->reset(), for example sfq just dequeue and free all queued skb.

Fixes 2ccccf5fb43f ("net_sched: update hierarchical backlog too")
---
 net/sched/sch_generic.c |    1 +
 1 file changed, 1 insertion(+)
net/sched/sch_generic.c +1 -0
@@ -681,6 +681,7 @@ void qdisc_reset(struct Qdisc *qdisc)
 		qdisc->gso_skb = NULL;
 	}
 	qdisc->q.qlen = 0;
+	qdisc->qstats.backlog = 0;
 }
 EXPORT_SYMBOL(qdisc_reset);
 
author maintainer
#62 lore raw

PATCH 63/105 net: qcom/emac: specify the correct size when mapping a DMA buffer

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Timur Tabi <[email protected]>

[ Upstream commit a93ad944f4ff9a797abff17c73fc4b1e4a1d9141 ]

When mapping the RX DMA buffers, the driver was accidentally specifying zero for the buffer length. Under normal circumstances, SWIOTLB does not need to allocate a bounce buffer, so the address is just mapped without checking the size field. This is why the error was not detected earlier.

Fixes b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
---
 drivers/net/ethernet/qualcomm/emac/emac-mac.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/emac/emac-mac.c +2 -1
@@ -932,7 +932,8 @@ static void emac_mac_rx_descs_refill(str
 
 		curr_rxbuf->dma_addr =
 			dma_map_single(adpt->netdev->dev.parent, skb->data,
-				       curr_rxbuf->length, DMA_FROM_DEVICE);
+				       adpt->rxbuf_size, DMA_FROM_DEVICE);
+
 		ret = dma_mapping_error(adpt->netdev->dev.parent,
 					curr_rxbuf->dma_addr);
 		if (ret) {
author maintainer
#63 lore raw

PATCH 64/105 vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 36f6ee22d2d66046e369757ec6bbe1c482957ba6 ]

When running LTP IPsec tests, KASan might report:

BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0
...
Call Trace:
  <IRQ>
  dump_stack+0x63/0x89
  print_address_description+0x7c/0x290
  kasan_report+0x28d/0x370
  ? vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
  __asan_report_load4_noabort+0x19/0x20
  vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
  ? vti_init_net+0x190/0x190 [ip_vti]
  ? save_stack_trace+0x1b/0x20
  ? save_stack+0x46/0xd0
  dev_hard_start_xmit+0x147/0x510
  ? icmp_echo.part.24+0x1f0/0x210
  __dev_queue_xmit+0x1394/0x1c60
...
Freed by task 0:
  save_stack_trace+0x1b/0x20
  save_stack+0x46/0xd0
  kasan_slab_free+0x70/0xc0
  kmem_cache_free+0x81/0x1e0
  kfree_skbmem+0xb1/0xe0
  kfree_skb+0x75/0x170
  kfree_skb_list+0x3e/0x60
  __dev_queue_xmit+0x1298/0x1c60
  dev_queue_xmit+0x10/0x20
  neigh_resolve_output+0x3a8/0x740
  ip_finish_output2+0x5c0/0xe70
  ip_finish_output+0x4ba/0x680
  ip_output+0x1c1/0x3a0
  xfrm_output_resume+0xc65/0x13d0
  xfrm_output+0x1e4/0x380
  xfrm4_output_finish+0x5c/0x70

Can be fixed if we get skb->len before dst_output().

Fixes b9959fd3b0fa ("vti: switch to new ip tunnel code")
Fixes 22e1b23dafa8 ("vti6: Support inter address family tunneling.")
---
 net/ipv4/ip_vti.c  |    3 ++-
 net/ipv6/ip6_vti.c |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)
net/ipv4/ip_vti.c +2 -1
@@ -168,6 +168,7 @@ static netdev_tx_t vti_xmit(struct sk_bu
 	struct ip_tunnel_parm *parms = &tunnel->parms;
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *tdev;	/* Device to other host */
+	int pkt_len = skb->len;
 	int err;
 	int mtu;
 
@@ -229,7 +230,7 @@ static netdev_tx_t vti_xmit(struct sk_bu
 
 	err = dst_output(tunnel->net, skb->sk, skb);
 	if (net_xmit_eval(err) == 0)
-		err = skb->len;
+		err = pkt_len;
 	iptunnel_xmit_stats(dev, err);
 	return NETDEV_TX_OK;
 
net/ipv6/ip6_vti.c +2 -1
@@ -445,6 +445,7 @@ vti6_xmit(struct sk_buff *skb, struct ne
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *tdev;
 	struct xfrm_state *x;
+	int pkt_len = skb->len;
 	int err = -1;
 	int mtu;
 
@@ -498,7 +499,7 @@ vti6_xmit(struct sk_buff *skb, struct ne
 		struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
 
 		u64_stats_update_begin(&tstats->syncp);
-		tstats->tx_bytes += skb->len;
+		tstats->tx_bytes += pkt_len;
 		tstats->tx_packets++;
 		u64_stats_update_end(&tstats->syncp);
 	} else {
author maintainer
#64 lore raw

PATCH 65/105 l2tp: Avoid schedule while atomic in exit_net

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ridge Kennedy <[email protected]>

[ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]

While destroying a network namespace that contains a L2TP tunnel a "BUG: scheduling while atomic" can be observed.

Enabling lockdep shows that this is happening because l2tp_exit_net() is calling l2tp_tunnel_closeall() (via l2tp_tunnel_delete()) from within an RCU critical section.

l2tp_exit_net() takes rcu_read_lock_bh()
<< list_for_each_entry_rcu() >>
l2tp_tunnel_delete()
l2tp_tunnel_closeall()
__l2tp_session_unhash()
synchronize_rcu() << Illegal inside RCU critical section >>

BUG: sleeping function called from invalid context
in_atomic(): 1, irqs_disabled(): 0, pid: 86, name: kworker/u16:2
INFO: lockdep is turned off.
CPU: 2 PID: 86 Comm: kworker/u16:2 Tainted: G        W  O    4.4.6-at1 #2
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125300 05/09/2016
Workqueue: netns cleanup_net
 0000000000000000 ffff880202417b90 ffffffff812b0013 ffff880202410ac0
 ffffffff81870de8 ffff880202417bb8 ffffffff8107aee8 ffffffff81870de8
 0000000000000c51 0000000000000000 ffff880202417be0 ffffffff8107b024
Call Trace:
 [<ffffffff812b0013>] dump_stack+0x85/0xc2
 [<ffffffff8107aee8>] ___might_sleep+0x148/0x240
 [<ffffffff8107b024>] __might_sleep+0x44/0x80
 [<ffffffff810b21bd>] synchronize_sched+0x2d/0xe0
 [<ffffffff8109be6d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff8105c7bb>] ? __local_bh_enable_ip+0x6b/0xc0
 [<ffffffff816a1b00>] ? _raw_spin_unlock_bh+0x30/0x40
 [<ffffffff81667482>] __l2tp_session_unhash+0x172/0x220
 [<ffffffff81667397>] ? __l2tp_session_unhash+0x87/0x220
 [<ffffffff8166888b>] l2tp_tunnel_closeall+0x9b/0x140
 [<ffffffff81668c74>] l2tp_tunnel_delete+0x14/0x60
 [<ffffffff81668dd0>] l2tp_exit_net+0x110/0x270
 [<ffffffff81668d5c>] ? l2tp_exit_net+0x9c/0x270
 [<ffffffff815001c3>] ops_exit_list.isra.6+0x33/0x60
 [<ffffffff81501166>] cleanup_net+0x1b6/0x280
 ...

This bug can easily be reproduced with a few steps:

 $ sudo unshare -n bash  # Create a shell in a new namespace
 # ip link set lo up
 # ip addr add 127.0.0.1 dev lo
 # ip l2tp add tunnel remote 127.0.0.1 local 127.0.0.1 tunnel_id 1 \
    peer_tunnel_id 1 udp_sport 50000 udp_dport 50000
 # ip l2tp add session name foo tunnel_id 1 session_id 1 \
    peer_session_id 1
 # ip link set foo up
 # exit  # Exit the shell, in turn exiting the namespace
 $ dmesg
 ...
 [942121.089216] BUG: scheduling while atomic: kworker/u16:3/13872/0x00000200
 ...

To fix this, move the call to l2tp_tunnel_closeall() out of the RCU critical section, and instead call it from l2tp_tunnel_del_work(), which is running from the l2tp_wq workqueue.

Fixes 2b551c6e7d5b ("l2tp: close sessions before initiating tunnel delete")
---
 net/l2tp/l2tp_core.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
net/l2tp/l2tp_core.c +3 -1
@@ -1415,6 +1415,9 @@ static void l2tp_tunnel_del_work(struct
 	struct sock *sk = NULL;
 
 	tunnel = container_of(work, struct l2tp_tunnel, del_work);
+
+	l2tp_tunnel_closeall(tunnel);
+
 	sk = l2tp_tunnel_sock_lookup(tunnel);
 	if (!sk)
 		goto out;
@@ -1737,7 +1740,6 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);
 int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
 {
 	l2tp_tunnel_inc_refcount(tunnel);
-	l2tp_tunnel_closeall(tunnel);
 	if (false == queue_work(l2tp_wq, &tunnel->del_work)) {
 		l2tp_tunnel_dec_refcount(tunnel);
 		return 1;
author maintainer
#65 lore raw

PATCH 66/105 l2tp: fix race condition in l2tp_tunnel_delete

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit 62b982eeb4589b2e6d7c01a90590e3a4c2b2ca19 ]

If we try to delete the same tunnel twice, the first delete operation does a lookup (l2tp_tunnel_get), finds the tunnel, calls l2tp_tunnel_delete, which queues it for deletion by l2tp_tunnel_del_work.

The second delete operation also finds the tunnel and calls l2tp_tunnel_delete. If the workqueue has already fired and started running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the same tunnel a second time, and try to free the socket again.

Add a dead flag to prevent firing the workqueue twice. Then we can remove the check of queue_work's result that was meant to prevent that race but doesn't.

Reproducer:

ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local 192.168.0.2 remote 192.168.0.1 encap udp udp_sport 5000 udp_dport 6000 ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000
ip link set l2tp1 up
ip l2tp del tunnel tunnel_id 3000
ip l2tp del tunnel tunnel_id 3000

Fixes f8ccac0e4493 ("l2tp: put tunnel socket release on a workqueue")
---
 net/l2tp/l2tp_core.c |   10 ++++------
 net/l2tp/l2tp_core.h |    5 ++++-
 2 files changed, 8 insertions(+), 7 deletions(-)
net/l2tp/l2tp_core.c +4 -6
@@ -1737,14 +1737,12 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);
 
 /* This function is used by the netlink TUNNEL_DELETE command.
  */
-int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
+void l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
 {
-	l2tp_tunnel_inc_refcount(tunnel);
-	if (false == queue_work(l2tp_wq, &tunnel->del_work)) {
-		l2tp_tunnel_dec_refcount(tunnel);
-		return 1;
+	if (!test_and_set_bit(0, &tunnel->dead)) {
+		l2tp_tunnel_inc_refcount(tunnel);
+		queue_work(l2tp_wq, &tunnel->del_work);
 	}
-	return 0;
 }
 EXPORT_SYMBOL_GPL(l2tp_tunnel_delete);
 
net/l2tp/l2tp_core.h +4 -1
@@ -169,6 +169,9 @@ struct l2tp_tunnel_cfg {
 
 struct l2tp_tunnel {
 	int			magic;		/* Should be L2TP_TUNNEL_MAGIC */
+
+	unsigned long		dead;
+
 	struct rcu_head rcu;
 	rwlock_t		hlist_lock;	/* protect session_hlist */
 	struct hlist_head	session_hlist[L2TP_HASH_SIZE];
@@ -257,7 +260,7 @@ int l2tp_tunnel_create(struct net *net,
 		       u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg,
 		       struct l2tp_tunnel **tunnelp);
 void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel);
-int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel);
+void l2tp_tunnel_delete(struct l2tp_tunnel *tunnel);
 struct l2tp_session *l2tp_session_create(int priv_size,
 					 struct l2tp_tunnel *tunnel,
 					 u32 session_id, u32 peer_session_id,
author maintainer
#66 lore raw

PATCH 67/105 tun: bail out from tun_get_user() if the skb is empty

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alexander Potapenko <[email protected]>

[ Upstream commit 2580c4c17aee3ad58e9751012bad278dd074ccae ]

KMSAN (https://github.com/google/kmsan) reported accessing uninitialized skb->data[0] in the case the skb is empty (i.e. skb->len is 0):

================================================

BUG: KMSAN: use of uninitialized memory in tun_get_user+0x19ba/0x3770
CPU: 0 PID: 3051 Comm: probe Not tainted 4.13.0+ #3140
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
...
 __msan_warning_32+0x66/0xb0 mm/kmsan/kmsan_instr.c:477
 tun_get_user+0x19ba/0x3770 drivers/net/tun.c:1301
 tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
 call_write_iter ./include/linux/fs.h:1743
 new_sync_write fs/read_write.c:457
 __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
 vfs_write+0x3e4/0x770 fs/read_write.c:518
 SYSC_write+0x12f/0x2b0 fs/read_write.c:565
 SyS_write+0x55/0x80 fs/read_write.c:557
 do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
 entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:245
...
origin:
...
 kmsan_poison_shadow+0x6e/0xc0 mm/kmsan/kmsan.c:211
 slab_alloc_node mm/slub.c:2732
 __kmalloc_node_track_caller+0x351/0x370 mm/slub.c:4351
 __kmalloc_reserve net/core/skbuff.c:138
 __alloc_skb+0x26a/0x810 net/core/skbuff.c:231
 alloc_skb ./include/linux/skbuff.h:903
 alloc_skb_with_frags+0x1d7/0xc80 net/core/skbuff.c:4756
 sock_alloc_send_pskb+0xabf/0xfe0 net/core/sock.c:2037
 tun_alloc_skb drivers/net/tun.c:1144
 tun_get_user+0x9a8/0x3770 drivers/net/tun.c:1274
 tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
 call_write_iter ./include/linux/fs.h:1743
 new_sync_write fs/read_write.c:457
 __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
 vfs_write+0x3e4/0x770 fs/read_write.c:518
 SYSC_write+0x12f/0x2b0 fs/read_write.c:565
 SyS_write+0x55/0x80 fs/read_write.c:557
 do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
 return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:245
================================================

Make sure tun_get_user() doesn't touch skb->data[0] unless there is actual data.

C reproducer below:
==========================

    // autogenerated by syzkaller (http://github.com/google/syzkaller)

    #define _GNU_SOURCE

    #include <fcntl.h>
    #include <linux/if_tun.h>
    #include <netinet/ip.h>
    #include <net/if.h>
    #include <string.h>
    #include <sys/ioctl.h>

    int main()
    {
      int sock = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
      int tun_fd = open("/dev/net/tun", O_RDWR);
      struct ifreq req;
      memset(&req, 0, sizeof(struct ifreq));
      strcpy((char*)&req.ifr_name, "gre0");
      req.ifr_flags = IFF_UP | IFF_MULTICAST;
      ioctl(tun_fd, TUNSETIFF, &req);
      ioctl(sock, SIOCSIFFLAGS, "gre0");
      write(tun_fd, "hi", 0);
      return 0;
    }

==========================

---
 drivers/net/tun.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/tun.c +5 -3
@@ -1279,11 +1279,13 @@ static ssize_t tun_get_user(struct tun_s
 	switch (tun->flags & TUN_TYPE_MASK) {
 	case IFF_TUN:
 		if (tun->flags & IFF_NO_PI) {
-			switch (skb->data[0] & 0xf0) {
-			case 0x40:
+			u8 ip_version = skb->len ? (skb->data[0] >> 4) : 0;
+
+			switch (ip_version) {
+			case 4:
 				pi.proto = htons(ETH_P_IP);
 				break;
-			case 0x60:
+			case 6:
 				pi.proto = htons(ETH_P_IPV6);
 				break;
 			default:
author maintainer
#67 lore raw

PATCH 68/105 net: dsa: Fix network device registration order

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Florian Fainelli <[email protected]>

[ Upstream commit e804441cfe0b60f6c430901946a69c01eac09df1 ]

We cannot be registering the network device first, then setting its carrier off and finally connecting it to a PHY, doing that leaves a window during which the carrier is at best inconsistent, and at worse the device is not usable without a down/up sequence since the network device is visible to user space with possibly no PHY device attached.

Re-order steps so that they make logical sense. This fixes some devices where the port was not usable after e.g: an unbind then bind of the driver.

Fixes 0071f56e46da ("dsa: Register netdev before phy")
Fixes 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
---
 net/dsa/slave.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)
net/dsa/slave.c +17 -11
@@ -1269,26 +1269,32 @@ int dsa_slave_create(struct dsa_switch *
 	p->old_duplex = -1;
 
 	ds->ports[port].netdev = slave_dev;
-	ret = register_netdev(slave_dev);
-	if (ret) {
-		netdev_err(master, "error %d registering interface %s\n",
-			   ret, slave_dev->name);
-		ds->ports[port].netdev = NULL;
-		free_netdev(slave_dev);
-		return ret;
-	}
 
 	netif_carrier_off(slave_dev);
 
 	ret = dsa_slave_phy_setup(p, slave_dev);
 	if (ret) {
 		netdev_err(master, "error %d setting up slave phy\n", ret);
-		unregister_netdev(slave_dev);
-		free_netdev(slave_dev);
-		return ret;
+		goto out_free;
+	}
+
+	ret = register_netdev(slave_dev);
+	if (ret) {
+		netdev_err(master, "error %d registering interface %s\n",
+			   ret, slave_dev->name);
+		goto out_phy;
 	}
 
 	return 0;
+
+out_phy:
+	phy_disconnect(p->phy);
+	if (of_phy_is_fixed_link(ds->ports[port].dn))
+		of_phy_deregister_fixed_link(ds->ports[port].dn);
+out_free:
+	free_netdev(slave_dev);
+	ds->ports[port].netdev = NULL;
+	return ret;
 }
 
 void dsa_slave_destroy(struct net_device *slave_dev)
author maintainer
#68 lore raw

PATCH 69/105 packet: in packet_do_bind, test fanout with bind_lock held

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Willem de Bruijn <[email protected]>

[ Upstream commit 4971613c1639d8e5f102c4e797c3bf8f83a5a69e ]

Once a socket has po->fanout set, it remains a member of the group until it is destroyed. The prot_hook must be constant and identical across sockets in the group.

If fanout_add races with packet_do_bind between the test of po->fanout and taking the lock, the bind call may make type or dev inconsistent with that of the fanout group.

Hold po->bind_lock when testing po->fanout to avoid this race.

I had to introduce artificial delay (local_bh_enable) to actually observe the race.

Fixes dc99f600698d ("packet: Add fanout support.")
---
 net/packet/af_packet.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
net/packet/af_packet.c +5 -3
@@ -3069,13 +3069,15 @@ static int packet_do_bind(struct sock *s
 	int ret = 0;
 	bool unlisted = false;
 
-	if (po->fanout)
-		return -EINVAL;
-
 	lock_sock(sk);
 	spin_lock(&po->bind_lock);
 	rcu_read_lock();
 
+	if (po->fanout) {
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
 	if (name) {
 		dev = dev_get_by_name_rcu(sock_net(sk), name);
 		if (!dev) {
author maintainer
#69 lore raw

PATCH 70/105 packet: only test po->has_vnet_hdr once in packet_snd

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Willem de Bruijn <[email protected]>

[ Upstream commit da7c9561015e93d10fe6aab73e9288e0d09d65a6 ]

Packet socket option po->has_vnet_hdr can be updated concurrently with other operations if no ring is attached.

Do not test the option twice in packet_snd, as the value may change in between calls. A race on setsockopt disable may cause a packet > mtu to be sent without having GSO options set.

Fixes bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
---
 net/packet/af_packet.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
net/packet/af_packet.c +4 -2
@@ -1713,7 +1713,7 @@ static int fanout_add(struct sock *sk, u
 	}
 	spin_unlock(&po->bind_lock);
 
-	if (err && !refcount_read(&match->sk_ref)) {
+	if (err && !atomic_read(&match->sk_ref)) {
 		list_del(&match->list);
 		kfree(match);
 	}
@@ -2838,6 +2838,7 @@ static int packet_snd(struct socket *soc
 	struct virtio_net_hdr vnet_hdr = { 0 };
 	int offset = 0;
 	struct packet_sock *po = pkt_sk(sk);
+	bool has_vnet_hdr = false;
 	int hlen, tlen, linear;
 	int extra_len = 0;
 
@@ -2881,6 +2882,7 @@ static int packet_snd(struct socket *soc
 		err = packet_snd_vnet_parse(msg, &len, &vnet_hdr);
 		if (err)
 			goto out_unlock;
+		has_vnet_hdr = true;
 	}
 
 	if (unlikely(sock_flag(sk, SOCK_NOFCS))) {
@@ -2941,7 +2943,7 @@ static int packet_snd(struct socket *soc
 
 	packet_pick_tx_queue(dev, skb);
 
-	if (po->has_vnet_hdr) {
+	if (has_vnet_hdr) {
 		err = packet_snd_vnet_gso(skb, &vnet_hdr);
 		if (err)
 			goto out_free;
author maintainer
#70 lore raw

PATCH 71/105 net: Set sk_prot_creator when cloning sockets to the right proto

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christoph Paasch <[email protected]>

[ Upstream commit 9d538fa60bad4f7b23193c89e843797a1cf71ef3 ]

sk->sk_prot and sk->sk_prot_creator can differ when the app uses IPV6_ADDRFORM (transforming an IPv6-socket to an IPv4-one). Which is why sk_prot_creator is there to make sure that sk_prot_free() does the kmem_cache_free() on the right kmem_cache slab.

Now, if such a socket gets transformed back to a listening socket (using connect() with AF_UNSPEC) we will allocate an IPv4 tcp_sock through sk_clone_lock() when a new connection comes in. But sk_prot_creator will still point to the IPv6 kmem_cache (as everything got copied in sk_clone_lock()). When freeing, we will thus put this
memory back into the IPv6 kmem_cache although it was allocated in the IPv4 cache. I have seen memory corruption happening because of this.

With slub-debugging and MEMCG_KMEM enabled this gives the warning
"cache_from_obj: Wrong slab cache. TCPv6 but object is from TCP"

A C-program to trigger this:

void main(void)

{
        int fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
        int new_fd, newest_fd, client_fd;
        struct sockaddr_in6 bind_addr;
        struct sockaddr_in bind_addr4, client_addr1, client_addr2;
        struct sockaddr unsp;
        int val;

        memset(&bind_addr, 0, sizeof(bind_addr));
        bind_addr.sin6_family = AF_INET6;
        bind_addr.sin6_port = ntohs(42424);

        memset(&client_addr1, 0, sizeof(client_addr1));
        client_addr1.sin_family = AF_INET;
        client_addr1.sin_port = ntohs(42424);
        client_addr1.sin_addr.s_addr = inet_addr("127.0.0.1");

        memset(&client_addr2, 0, sizeof(client_addr2));
        client_addr2.sin_family = AF_INET;
        client_addr2.sin_port = ntohs(42421);
        client_addr2.sin_addr.s_addr = inet_addr("127.0.0.1");

        memset(&unsp, 0, sizeof(unsp));
        unsp.sa_family = AF_UNSPEC;

        bind(fd, (struct sockaddr *)&bind_addr, sizeof(bind_addr));

        listen(fd, 5);

        client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
        connect(client_fd, (struct sockaddr *)&client_addr1, sizeof(client_addr1));
        new_fd = accept(fd, NULL, NULL);
        close(fd);

        val = AF_INET;
        setsockopt(new_fd, SOL_IPV6, IPV6_ADDRFORM, &val, sizeof(val));

        connect(new_fd, &unsp, sizeof(unsp));

        memset(&bind_addr4, 0, sizeof(bind_addr4));
        bind_addr4.sin_family = AF_INET;
        bind_addr4.sin_port = ntohs(42421);
        bind(new_fd, (struct sockaddr *)&bind_addr4, sizeof(bind_addr4));

        listen(new_fd, 5);

        client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
        connect(client_fd, (struct sockaddr *)&client_addr2, sizeof(client_addr2));

        newest_fd = accept(new_fd, NULL, NULL);
        close(new_fd);

        close(client_fd);
        close(new_fd);
}

As far as I can see, this bug has been there since the beginning of the git-days.

---
 net/core/sock.c |    2 ++
 1 file changed, 2 insertions(+)
net/core/sock.c +2 -0
@@ -1493,6 +1493,8 @@ struct sock *sk_clone_lock(const struct
 
 		sock_copy(newsk, sk);
 
+		newsk->sk_prot_creator = sk->sk_prot;
+
 		/* SANITY */
 		if (likely(newsk->sk_net_refcnt))
 			get_net(sock_net(newsk));
author maintainer
#71 lore raw

PATCH 72/105 netlink: do not proceed if dumps start() errs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Jason A. Donenfeld" <[email protected]>

[ Upstream commit fef0035c0f31322d417d1954bba5ab959bf91183 ]

Drivers that use the start method for netlink dumping rely on dumpit not being called if start fails. For example, ila_xlat.c allocates memory and assigns it to cb->args[0] in its start() function. It might fail to do that and return -ENOMEM instead. However, even when returning an error, dumpit will be called, which, in the example above, quickly dereferences the memory in cb->args[0], which will OOPS the kernel. This is but one example of how this goes wrong.

Since start() has always been a function with an int return type, it therefore makes sense to use it properly, rather than ignoring it. This patch thus returns early and does not call dumpit() when start() fails.

---
 net/netlink/af_netlink.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
net/netlink/af_netlink.c +5 -2
@@ -2211,10 +2211,13 @@ int __netlink_dump_start(struct sock *ss
 
 	mutex_unlock(nlk->cb_mutex);
 
+	ret = 0;
 	if (cb->start)
-		cb->start(cb);
+		ret = cb->start(cb);
+
+	if (!ret)
+		ret = netlink_dump(sk);
 
-	ret = netlink_dump(sk);
 	sock_put(sk);
 
 	if (ret)
author maintainer
#72 lore raw

PATCH 73/105 ip6_gre: ip6gre_tap device should keep dst

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Xin Long <[email protected]>

[ Upstream commit 2d40557cc702ed8e5edd9bd422233f86652d932e ]

The patch 'ip_gre: ipgre_tap device should keep dst' fixed a issue that ipgre_tap mtu couldn't be updated in tx path.

The same fix is needed for ip6gre_tap as well.

---
 net/ipv6/ip6_gre.c |    1 +
 1 file changed, 1 insertion(+)
net/ipv6/ip6_gre.c +1 -0
@@ -1298,6 +1298,7 @@ static void ip6gre_tap_setup(struct net_
 	dev->features |= NETIF_F_NETNS_LOCAL;
 	dev->priv_flags &= ~IFF_TX_SKB_SHARING;
 	dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+	netif_keep_dst(dev);
 }
 
 static bool ip6gre_netlink_encap_parms(struct nlattr *data[],
author maintainer
#73 lore raw

PATCH 74/105 ip6_tunnel: update mtu properly for ARPHRD_ETHER tunnel device in tx path

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Xin Long <[email protected]>

[ Upstream commit d41bb33ba33b8f8debe54ed36be6925eb496e354 ]

Now when updating mtu in tx path, it doesn't consider ARPHRD_ETHER tunnel device, like ip6gre_tap tunnel, for which it should also subtract ether header to get the correct mtu.

---
 net/ipv6/ip6_tunnel.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
net/ipv6/ip6_tunnel.c +3 -2
@@ -1042,6 +1042,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, st
 	struct dst_entry *dst = NULL, *ndst = NULL;
 	struct net_device *tdev;
 	int mtu;
+	unsigned int eth_hlen = t->dev->type == ARPHRD_ETHER ? ETH_HLEN : 0;
 	unsigned int psh_hlen = sizeof(struct ipv6hdr) + t->encap_hlen;
 	unsigned int max_headroom = psh_hlen;
 	bool use_cache = false;
@@ -1120,7 +1121,7 @@ route_lookup:
 				     t->parms.name);
 		goto tx_err_dst_release;
 	}
-	mtu = dst_mtu(dst) - psh_hlen - t->tun_hlen;
+	mtu = dst_mtu(dst) - eth_hlen - psh_hlen - t->tun_hlen;
 	if (encap_limit >= 0) {
 		max_headroom += 8;
 		mtu -= 8;
@@ -1129,7 +1130,7 @@ route_lookup:
 		mtu = IPV6_MIN_MTU;
 	if (skb_dst(skb) && !t->parms.collect_md)
 		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
-	if (skb->len - t->tun_hlen > mtu && !skb_is_gso(skb)) {
+	if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
 		*pmtu = mtu;
 		err = -EMSGSIZE;
 		goto tx_err_dst_release;
author maintainer
#74 lore raw

PATCH 75/105 tipc: use only positive error codes in messages

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Parthasarathy Bhuvaragan <[email protected]>

[ Upstream commit aad06212d36cf34859428a0a279e5c14ee5c9e26 ]

In commit e3a77561e7d32 ("tipc: split up function tipc_msg_eval()"), we have updated the function tipc_msg_lookup_dest() to set the error codes to negative values at destination lookup failures. Thus when the function sets the error code to -TIPC_ERR_NO_NAME, its inserted into the 4 bit error field of the message header as 0xf instead of TIPC_ERR_NO_NAME (1). The value 0xf is an unknown error code.

In this commit, we set only positive error code.

Fixes e3a77561e7d32 ("tipc: split up function tipc_msg_eval()")
---
 net/tipc/msg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/tipc/msg.c +1 -1
@@ -547,7 +547,7 @@ bool tipc_msg_lookup_dest(struct net *ne
 		return false;
 	if (msg_errcode(msg))
 		return false;
-	*err = -TIPC_ERR_NO_NAME;
+	*err = TIPC_ERR_NO_NAME;
 	if (skb_linearize(skb))
 		return false;
 	msg = buf_msg(skb);
author maintainer
#75 lore raw

PATCH 76/105 net: rtnetlink: fix info leak in RTM_GETSTATS call

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Nikolay Aleksandrov <[email protected]>

[ Upstream commit ce024f42c2e28b6bce4ecc1e891b42f57f753892 ]

When RTM_GETSTATS was added the fields of its header struct were not all initialized when returning the result thus leaking 4 bytes of information to user-space per rtnl_fill_statsinfo call, so initialize them now. Thanks to Alexander Potapenko for the detailed report and bisection.

Fixes 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump link stats")
---
 net/core/rtnetlink.c |    3 +++
 1 file changed, 3 insertions(+)
net/core/rtnetlink.c +3 -0
@@ -3758,6 +3758,9 @@ static int rtnl_fill_statsinfo(struct sk
 		return -EMSGSIZE;
 
 	ifsm = nlmsg_data(nlh);
+	ifsm->family = PF_UNSPEC;
+	ifsm->pad1 = 0;
+	ifsm->pad2 = 0;
 	ifsm->ifindex = dev->ifindex;
 	ifsm->filter_mask = filter_mask;
 
author maintainer
#76 lore raw

PATCH 77/105 socket, bpf: fix possible use after free

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>

[ Upstream commit eefca20eb20c66b06cf5ed09b49b1a7caaa27b7b ]

Starting from linux-4.4, 3WHS no longer takes the listener lock.

Since this time, we might hit a use-after-free in sk_filter_charge(), if the filter we got in the memcpy() of the listener content just happened to be replaced by a thread changing listener BPF filter.

To fix this, we need to make sure the filter refcount is not already zero before incrementing it again.

Fixes e994b2f0fb92 ("tcp: do not lock listener to process SYN packets")
---
 net/core/filter.c |   15 +++++++++++++--
 net/core/sock.c   |    5 ++++-
 2 files changed, 17 insertions(+), 3 deletions(-)
net/core/filter.c +13 -2
@@ -937,20 +937,31 @@ void sk_filter_uncharge(struct sock *sk,
 /* try to charge the socket memory if there is space available
  * return true on success
  */
-bool sk_filter_charge(struct sock *sk, struct sk_filter *fp)
+static bool __sk_filter_charge(struct sock *sk, struct sk_filter *fp)
 {
 	u32 filter_size = bpf_prog_size(fp->prog->len);
 
 	/* same check as in sock_kmalloc() */
 	if (filter_size <= sysctl_optmem_max &&
 	    atomic_read(&sk->sk_omem_alloc) + filter_size < sysctl_optmem_max) {
-		atomic_inc(&fp->refcnt);
 		atomic_add(filter_size, &sk->sk_omem_alloc);
 		return true;
 	}
 	return false;
 }
 
+bool sk_filter_charge(struct sock *sk, struct sk_filter *fp)
+{
+	if (!atomic_inc_not_zero(&fp->refcnt))
+		return false;
+
+	if (!__sk_filter_charge(sk, fp)) {
+		sk_filter_release(fp);
+		return false;
+	}
+	return true;
+}
+
 static struct bpf_prog *bpf_migrate_filter(struct bpf_prog *fp)
 {
 	struct sock_filter *old_prog;
net/core/sock.c +4 -1
@@ -1528,13 +1528,16 @@ struct sock *sk_clone_lock(const struct
 		sock_reset_flag(newsk, SOCK_DONE);
 		skb_queue_head_init(&newsk->sk_error_queue);
 
-		filter = rcu_dereference_protected(newsk->sk_filter, 1);
+		rcu_read_lock();
+		filter = rcu_dereference(sk->sk_filter);
 		if (filter != NULL)
 			/* though it's an empty new sock, the charging may fail
 			 * if sysctl_optmem_max was changed between creation of
 			 * original socket and cloning
 			 */
 			is_charged = sk_filter_charge(newsk, filter);
+		RCU_INIT_POINTER(newsk->sk_filter, filter);
+		rcu_read_unlock();
 
 		if (unlikely(!is_charged || xfrm_sk_clone_policy(newsk, sk))) {
 			/* We need to make sure that we don't uncharge the new
author maintainer
#77 lore raw

PATCH 78/105 powerpc/64s: Use emergency stack for kernel TM Bad Thing program checks

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Cyril Bur <[email protected]>

commit 265e60a170d0a0ecfc2d20490134ed2c48dd45ab upstream.

When using transactional memory (TM), the CPU can be in one of six states as far as TM is concerned, encoded in the Machine State Register (MSR). Certain state transitions are illegal and if attempted trigger a "TM Bad Thing" type program check exception.

If we ever hit one of these exceptions it's treated as a bug, ie. we oops, and kill the process and/or panic, depending on configuration.

One case where we can trigger a TM Bad Thing, is when returning to userspace after a system call or interrupt, using RFID. When this happens the CPU first restores the user register state, in particular r1 (the stack pointer) and then attempts to update the MSR. However the MSR update is not allowed and so we take the program check with the user register state, but the kernel MSR.

This tricks the exception entry code into thinking we have a bad kernel stack pointer, because the MSR says we're coming from the kernel, but r1 is pointing to userspace.

To avoid this we instead always switch to the emergency stack if we take a TM Bad Thing from the kernel. That way none of the user register values are used, other than for printing in the oops message.

This is the fix for CVE-2017-1000255.

Fixes 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
[mpe: Rewrite change log & comments, tweak asm slightly]
---
 arch/powerpc/kernel/exceptions-64s.S |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)
arch/powerpc/kernel/exceptions-64s.S +23 -1
@@ -764,7 +764,29 @@ EXC_REAL(program_check, 0x700, 0x800)
 EXC_VIRT(program_check, 0x4700, 0x4800, 0x700)
 TRAMP_KVM(PACA_EXGEN, 0x700)
 EXC_COMMON_BEGIN(program_check_common)
-	EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN)
+	/*
+	 * It's possible to receive a TM Bad Thing type program check with
+	 * userspace register values (in particular r1), but with SRR1 reporting
+	 * that we came from the kernel. Normally that would confuse the bad
+	 * stack logic, and we would report a bad kernel stack pointer. Instead
+	 * we switch to the emergency stack if we're taking a TM Bad Thing from
+	 * the kernel.
+	 */
+	li	r10,MSR_PR		/* Build a mask of MSR_PR ..	*/
+	oris	r10,r10,0x200000@h	/* .. and SRR1_PROGTM		*/
+	and	r10,r10,r12		/* Mask SRR1 with that.		*/
+	srdi	r10,r10,8		/* Shift it so we can compare	*/
+	cmpldi	r10,(0x200000 >> 8)	/* .. with an immediate.	*/
+	bne 1f				/* If != go to normal path.	*/
+
+	/* SRR1 had PR=0 and SRR1_PROGTM=1, so use the emergency stack	*/
+	andi.	r10,r12,MSR_PR;		/* Set CR0 correctly for label	*/
+					/* 3 in EXCEPTION_PROLOG_COMMON	*/
+	mr	r10,r1			/* Save r1			*/
+	ld	r1,PACAEMERGSP(r13)	/* Use emergency stack		*/
+	subi	r1,r1,INT_FRAME_SIZE	/* alloc stack frame		*/
+	b 3f				/* Jump into the macro !!	*/
+1:	EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN)
 	bl	save_nvgprs
 	RECONCILE_IRQ_STATE(r10, r11)
 	addi	r3,r1,STACK_FRAME_OVERHEAD
author maintainer
#78 lore raw

PATCH 79/105 powerpc/tm: Fix illegal TM state in signal handler

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Gustavo Romero <[email protected]>

commit 044215d145a7a8a60ffa8fdc859d110a795fa6ea upstream.

Currently it's possible that on returning from the signal handler through the restore_tm_sigcontexts() code path (e.g. from a signal caught due to a trap instruction executed in the middle of an HTM block, or a deliberately constructed sigframe) an illegal TM state (like TS=10 TM=0, i.e. "T0") is set in SRR1 and when rfid sets implicitly the MSR register from SRR1 register on return to userspace it causes a TM Bad Thing exception.

That illegal state can be set (a) by a malicious user that disables the TM bit by tweaking the bits in uc_mcontext before returning from the signal handler or (b) by a sufficient number of context switches occurring such that the load_tm counter overflows and TM is disabled whilst in the signal handler.

This commit fixes the illegal TM state by ensuring that TM bit is always enabled before we return from restore_tm_sigcontexts(). A small comment correction is made as well.

Fixes 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
---
 arch/powerpc/kernel/signal_64.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)
arch/powerpc/kernel/signal_64.c +12 -1
@@ -452,9 +452,20 @@ static long restore_tm_sigcontexts(struc
 	if (MSR_TM_RESV(msr))
 		return -EINVAL;
 
-	/* pull in MSR TM from user context */
+	/* pull in MSR TS bits from user context */
 	regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK);
 
+	/*
+	 * Ensure that TM is enabled in regs->msr before we leave the signal
+	 * handler. It could be the case that (a) user disabled the TM bit
+	 * through the manipulation of the MSR bits in uc_mcontext or (b) the
+	 * TM bit was disabled because a sufficient number of context switches
+	 * happened whilst in the signal handler and load_tm overflowed,
+	 * disabling the TM bit. In either case we can end up with an illegal
+	 * TM state leading to a TM Bad Thing when we return to userspace.
+	 */
+	regs->msr |= MSR_TM;
+
 	/* pull in MSR LE from user context */
 	regs->msr = (regs->msr & ~MSR_LE) | (msr & MSR_LE);
 
author maintainer
#79 lore raw

PATCH 80/105 percpu: make this_cpu_generic_read() atomic w.r.t. interrupts

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mark Rutland <[email protected]>

commit e88d62cd4b2f0b1ae55e9008e79c2794b1fc914d upstream.

As raw_cpu_generic_read() is a plain read from a raw_cpu_ptr() address, it's possible (albeit unlikely) that the compiler will split the access across multiple instructions.

In this_cpu_generic_read() we disable preemption but not interrupts before calling raw_cpu_generic_read(). Thus, an interrupt could be taken in the middle of the split load instructions. If a this_cpu_write() or RMW this_cpu_*() op is made to the same variable in the interrupt handling path, this_cpu_read() will return a torn value.

For native word types, we can avoid tearing using READ_ONCE(), but this won't work in all cases (e.g. 64-bit types on most 32-bit platforms). This patch reworks this_cpu_generic_read() to use READ_ONCE() where possible, otherwise falling back to disabling interrupts.

Cc Arnd Bergmann <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Pranith Kumar <[email protected]>
Cc Tejun Heo <[email protected]>
Cc Thomas Gleixner <[email protected]>
---
 include/asm-generic/percpu.h |   24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)
include/asm-generic/percpu.h +22 -2
@@ -115,15 +115,35 @@ do {									\
 	(__ret);							\
 })
 
-#define this_cpu_generic_read(pcp)					\
+#define __this_cpu_generic_read_nopreempt(pcp)				\
 ({									\
 	typeof(pcp) __ret;						\
 	preempt_disable_notrace();					\
-	__ret = raw_cpu_generic_read(pcp);				\
+	__ret = READ_ONCE(*raw_cpu_ptr(&(pcp)));			\
 	preempt_enable_notrace();					\
 	__ret;								\
 })
 
+#define __this_cpu_generic_read_noirq(pcp)				\
+({									\
+	typeof(pcp) __ret;						\
+	unsigned long __flags;						\
+	raw_local_irq_save(__flags);					\
+	__ret = raw_cpu_generic_read(pcp);				\
+	raw_local_irq_restore(__flags);					\
+	__ret;								\
+})
+
+#define this_cpu_generic_read(pcp)					\
+({									\
+	typeof(pcp) __ret;						\
+	if (__native_word(pcp))						\
+		__ret = __this_cpu_generic_read_nopreempt(pcp);		\
+	else								\
+		__ret = __this_cpu_generic_read_noirq(pcp);		\
+	__ret;								\
+})
+
 #define this_cpu_generic_to_op(pcp, val, op)				\
 do {									\
 	unsigned long __flags;						\
author maintainer
#80 lore raw

PATCH 81/105 driver core: platform: Dont read past the end of "driver_override" buffer

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolai Stange <[email protected]>

commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd upstream.

When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count+1 bytes for printing.

Reject driver_override values of these lengths in driver_override_store().

This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the end of sysfs "driver_override" buffer") from Sasha Levin.

Fixes 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
---
 drivers/base/platform.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/base/platform.c +2 -1
@@ -858,7 +858,8 @@ static ssize_t driver_override_store(str
 	struct platform_device *pdev = to_platform_device(dev);
 	char *driver_override, *old, *cp;
 
-	if (count > PATH_MAX)
+	/* We need to keep extra room for a newline */
+	if (count >= (PAGE_SIZE - 1))
 		return -EINVAL;
 
 	driver_override = kstrndup(buf, count, GFP_KERNEL);
author maintainer
#81 lore raw

PATCH 82/105 Drivers: hv: fcopy: restore correct transfer length

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Olaf Hering <[email protected]>

commit 549e658a0919e355a2b2144dc380b3729bef7f3e upstream.

Till recently the expected length of bytes read by the daemon did depend on the context. It was either hv_start_fcopy or hv_do_fcopy. The daemon had a buffer size of two pages, which was much larger than needed.

Now the expected length of bytes read by the
daemon changed slightly. For START_FILE_COPY it is still the size of hv_start_fcopy. But for WRITE_TO_FILE and the other operations it is as large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE that is slightly larger than a struct hv_do_fcopy. Since the buffer in the daemon was still larger everything was fine.

Currently, the daemon reads only what is actually needed. The new buffer layout is as large as a struct hv_do_fcopy, for the WRITE_TO_FILE operation. Since the kernel expects a slightly larger size, hvt_op_read will return -EINVAL because the daemon will read slightly less than expected. Address this by restoring the expected buffer size in case of WRITE_TO_FILE.

Fixes 'c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")'
Fixes '3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")'
---
 drivers/hv/hv_fcopy.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/hv/hv_fcopy.c +4 -0
@@ -161,6 +161,10 @@ static void fcopy_send_data(struct work_
 		out_src = smsg_out;
 		break;
 
+	case WRITE_TO_FILE:
+		out_src = fcopy_transaction.fcopy_msg;
+		out_len = sizeof(struct hv_do_fcopy);
+		break;
 	default:
 		out_src = fcopy_transaction.fcopy_msg;
 		out_len = fcopy_transaction.recv_len;
author maintainer
#82 lore raw

PATCH 83/105 stm class: Fix a use-after-free

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alexander Shishkin <[email protected]>

commit fd085bb1766d6a598f53af2308374a546a49775a upstream.

For reasons unknown, the stm_source removal path uses device_destroy() to kill the underlying device object. Because device_destroy() uses devt to look for the device to destroy and the fact that stm_source devices don't have one (or all have the same one), it just picks the first device in the class, which may well be the wrong one.

That is, loading stm_console and stm_heartbeat and then removing both will die in dereferencing a freed object.

Since this should have been device_unregister() in the first place, use it instead of device_destroy().

Fixes 7bd1d4093c2 ("stm class: Introduce an abstraction for System Trace Module devices")
---
 drivers/hwtracing/stm/core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/stm/core.c +1 -1
@@ -1119,7 +1119,7 @@ void stm_source_unregister_device(struct
 
 	stm_source_link_drop(src);
 
-	device_destroy(&stm_source_class, src->dev.devt);
+	device_unregister(&src->dev);
 }
 EXPORT_SYMBOL_GPL(stm_source_unregister_device);
 
author maintainer
#83 lore raw

PATCH 84/105 ftrace: Fix kmemleak in unregister_ftrace_graph

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Shu Wang <[email protected]>

commit 2b0b8499ae75df91455bbeb7491d45affc384fb0 upstream.

The trampoline allocated by function tracer was overwriten by function_graph tracer, and caused a memory leak. The save_global_trampoline should have saved the previous trampoline in register_ftrace_graph() and restored it in unregister_ftrace_graph(). But as it is implemented, save_global_trampoline was only used in unregister_ftrace_graph as default value 0, and it overwrote the previous trampoline's value. Causing the previous allocated trampoline to be lost.

kmmeleak backtrace:

    kmemleak_vmalloc+0x77/0xc0
    __vmalloc_node_range+0x1b5/0x2c0
    module_alloc+0x7c/0xd0
    arch_ftrace_update_trampoline+0xb5/0x290
    ftrace_startup+0x78/0x210
    register_ftrace_function+0x8b/0xd0
    function_trace_init+0x4f/0x80
    tracing_set_tracer+0xe6/0x170
    tracing_set_trace_write+0x90/0xd0
    __vfs_write+0x37/0x170
    vfs_write+0xb2/0x1b0
    SyS_write+0x55/0xc0
    do_syscall_64+0x67/0x180
    return_from_SYSCALL_64+0x0/0x6a

[
Looking further into this, I found that this was left over from when the function and function graph tracers shared the same ftrace_ops. But in commit 5f151b2401 ("ftrace: Fix function_profiler and function tracer together"), the two were separated, and the save_global_trampoline no longer was necessary (and it may have been broken back then too). -- Steven Rostedt
]

Fixes 5f151b2401 ("ftrace: Fix function_profiler and function tracer together")
---
 kernel/trace/ftrace.c |   14 --------------
 1 file changed, 14 deletions(-)
kernel/trace/ftrace.c +0 -14
@@ -4381,9 +4381,6 @@ static char ftrace_graph_buf[FTRACE_FILT
 static char ftrace_graph_notrace_buf[FTRACE_FILTER_SIZE] __initdata;
 static int ftrace_set_func(unsigned long *array, int *idx, int size, char *buffer);
 
-static unsigned long save_global_trampoline;
-static unsigned long save_global_flags;
-
 static int __init set_graph_function(char *str)
 {
 	strlcpy(ftrace_graph_buf, str, FTRACE_FILTER_SIZE);
@@ -5981,17 +5978,6 @@ void unregister_ftrace_graph(void)
 	unregister_pm_notifier(&ftrace_suspend_notifier);
 	unregister_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
 
-#ifdef CONFIG_DYNAMIC_FTRACE
-	/*
-	 * Function graph does not allocate the trampoline, but
-	 * other global_ops do. We need to reset the ALLOC_TRAMP flag
-	 * if one was used.
-	 */
-	global_ops.trampoline = save_global_trampoline;
-	if (save_global_flags & FTRACE_OPS_FL_ALLOC_TRAMP)
-		global_ops.flags |= FTRACE_OPS_FL_ALLOC_TRAMP;
-#endif
-
  out:
 	mutex_unlock(&ftrace_lock);
 }
author maintainer
#84 lore raw

PATCH 85/105 HID: i2c-hid: allocate hid buffers for real worst case

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Adrian Salido <[email protected]>

commit 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b upstream.

The buffer allocation is not currently accounting for an extra byte for the report id. This can cause an out of bounds access in function i2c_hid_set_or_send_report() with reportID > 15.

---
 drivers/hid/i2c-hid/i2c-hid.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/hid/i2c-hid/i2c-hid.c +2 -1
@@ -604,7 +604,8 @@ static int i2c_hid_alloc_buffers(struct
 {
 	/* the worst case is computed from the set_report command with a
 	 * reportID > 15 and the maximum report length */
-	int args_len = sizeof(__u8) + /* optional ReportID byte */
+	int args_len = sizeof(__u8) + /* ReportID */
+		       sizeof(__u8) + /* optional ReportID byte */
 		       sizeof(__u16) + /* data register */
 		       sizeof(__u16) + /* size of the report */
 		       report_size; /* report */
author maintainer
#85 lore raw

PATCH 86/105 HID: wacom: leds: Dont try to control the EKRs read-only LEDs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Aaron Armstrong Skomra <[email protected]>

commit 74aebed6dc13425233f2224668353cff7a112776 upstream.

Commit a50aac7193f1 introduces 'led.groups' and adds EKR support for these groups. However, unlike the other devices with LEDs, the EKR's LEDs are read-only and we shouldn't attempt to control them in wacom_led_control().

See bug: https://sourceforge.net/p/linuxwacom/bugs/342/

Fixes a50aac7193f1 ("HID: wacom: leds: dynamically allocate LED groups")
---
 drivers/hid/wacom_sys.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/hid/wacom_sys.c +3 -0
@@ -712,6 +712,9 @@ static int wacom_led_control(struct waco
 	if (!wacom->led.groups)
 		return -ENOTSUPP;
 
+	if (wacom->wacom_wac.features.type == REMOTE)
+		return -ENOTSUPP;
+
 	if (wacom->wacom_wac.pid) { /* wireless connected */
 		report_id = WAC_CMD_WL_LED_CONTROL;
 		buf_size = 13;
author maintainer
#86 lore raw

PATCH 87/105 HID: wacom: Always increment hdev refcount within wacom_get_hdev_data

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jason Gerecke <[email protected]>

commit 2a5e597c6bb1b873e473e5f57147e9e5d2755430 upstream.

The wacom_get_hdev_data function is used to find and return a reference to the "other half" of a Wacom device (i.e., the touch device associated with a pen, or vice-versa). To ensure these references are properly accounted for, the function is supposed to automatically increment the refcount before returning. This was not done, however, for devices which have pen & touch on different interfaces of the same USB device. This can lead to a WARNING ("refcount_t: underflow; use-after-free") when removing the module or device as we call kref_put() more times than kref_get(). Triggering an "actual" use- after-free would be difficult since both devices will disappear nearly- simultaneously. To silence this warning and prevent the potential error, we need to increment the refcount for all cases within wacom_get_hdev_data.

Fixes 41372d5d40 ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC")
---
 drivers/hid/wacom_sys.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hid/wacom_sys.c +3 -1
@@ -611,8 +611,10 @@ static struct wacom_hdev_data *wacom_get
 
 	/* Try to find an already-probed interface from the same device */
 	list_for_each_entry(data, &wacom_udev_list, list) {
-		if (compare_device_paths(hdev, data->dev, '/'))
+		if (compare_device_paths(hdev, data->dev, '/')) {
+			kref_get(&data->kref);
 			return data;
+		}
 	}
 
 	/* Fallback to finding devices that appear to be "siblings" */
author maintainer
#87 lore raw

PATCH 88/105 HID: wacom: bits shifted too much for 9th and 10th buttons

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ping Cheng <[email protected]>

commit ce06760ba46b66dae50f2519ae76bd15e89b5710 upstream.

Cintiq 12 has 10 expresskey buttons. The bit shift for the last two buttons were off by 5.

Fixes c7f0522 ("HID: wacom: Slim down wacom_intuos_pad processing")
---
 drivers/hid/wacom_wac.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hid/wacom_wac.c +2 -2
@@ -559,8 +559,8 @@ static int wacom_intuos_pad(struct wacom
 				keys = data[9] & 0x07;
 			}
 		} else {
-			buttons = ((data[6] & 0x10) << 10) |
-			          ((data[5] & 0x10) << 9)  |
+			buttons = ((data[6] & 0x10) << 5)  |
+			          ((data[5] & 0x10) << 4)  |
 			          ((data[6] & 0x0F) << 4)  |
 			          (data[5] & 0x0F);
 		}
author maintainer
#88 lore raw

PATCH 89/105 rocker: fix rocker_tlv_put_* functions for KASAN

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

commit 6098d7ddd62f532f80ee2a4b01aca500a8e4e9e4 upstream.

Inlining these functions creates lots of stack variables that each take 64 bytes when KASAN is enabled, leading to this warning about potential stack overflow:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

gcc-8 can now consolidate the stack slots itself, but on older versions we get the same behavior by using a temporary variable that holds a copy of the inline function argument.

---
 drivers/net/ethernet/rocker/rocker_tlv.h |   48 +++++++++++++++++++------------
 1 file changed, 30 insertions(+), 18 deletions(-)
drivers/net/ethernet/rocker/rocker_tlv.h +30 -18
@@ -139,40 +139,52 @@ rocker_tlv_start(struct rocker_desc_info
 int rocker_tlv_put(struct rocker_desc_info *desc_info,
 		   int attrtype, int attrlen, const void *data);
 
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
-				    int attrtype, u8 value)
+static inline int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &value);
+	u8 tmp = value; /* work around GCC PR81715 */
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &tmp);
 }
 
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-				     int attrtype, u16 value)
+static inline int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &value);
+	u16 tmp = value;
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &tmp);
 }
 
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
-				      int attrtype, __be16 value)
+static inline int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &value);
+	__be16 tmp = value;
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &tmp);
 }
 
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-				     int attrtype, u32 value)
+static inline int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &value);
+	u32 tmp = value;
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &tmp);
 }
 
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
-				      int attrtype, __be32 value)
+static inline int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &value);
+	__be32 tmp = value;
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &tmp);
 }
 
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-				     int attrtype, u64 value)
+static inline int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
 {
-	return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &value);
+	u64 tmp = value;
+
+	return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &tmp);
 }
 
 static inline struct rocker_tlv *
author maintainer
#89 lore raw

PATCH 90/105 netlink: fix nla_put_{u8,u16,u32} for KASAN

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

commit b4391db42308c9940944b5d7be5ca4b78fb88dd0 upstream.

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y").

The kernelci.org build bot however has the warning enabled and that led me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Most of this problem is now solved in gcc-8, which can consolidate the stack slots for the inline function arguments. On older compilers we can add a workaround by declaring a local variable in each function to pass the inline function argument.

---
 include/net/netlink.h |   73 +++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 55 insertions(+), 18 deletions(-)
include/net/netlink.h +55 -18
@@ -756,7 +756,10 @@ static inline int nla_parse_nested(struc
  */
 static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
 {
-	return nla_put(skb, attrtype, sizeof(u8), &value);
+	/* temporary variables to work around GCC PR81715 with asan-stack=1 */
+	u8 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(u8), &tmp);
 }
 
 /**
@@ -767,7 +770,9 @@ static inline int nla_put_u8(struct sk_b
  */
 static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
 {
-	return nla_put(skb, attrtype, sizeof(u16), &value);
+	u16 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(u16), &tmp);
 }
 
 /**
@@ -778,7 +783,9 @@ static inline int nla_put_u16(struct sk_
  */
 static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
 {
-	return nla_put(skb, attrtype, sizeof(__be16), &value);
+	__be16 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(__be16), &tmp);
 }
 
 /**
@@ -789,7 +796,9 @@ static inline int nla_put_be16(struct sk
  */
 static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 value)
 {
-	return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+	__be16 tmp = value;
+
+	return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
 }
 
 /**
@@ -800,7 +809,9 @@ static inline int nla_put_net16(struct s
  */
 static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
 {
-	return nla_put(skb, attrtype, sizeof(__le16), &value);
+	__le16 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(__le16), &tmp);
 }
 
 /**
@@ -811,7 +822,9 @@ static inline int nla_put_le16(struct sk
  */
 static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
 {
-	return nla_put(skb, attrtype, sizeof(u32), &value);
+	u32 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(u32), &tmp);
 }
 
 /**
@@ -822,7 +835,9 @@ static inline int nla_put_u32(struct sk_
  */
 static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
 {
-	return nla_put(skb, attrtype, sizeof(__be32), &value);
+	__be32 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(__be32), &tmp);
 }
 
 /**
@@ -833,7 +848,9 @@ static inline int nla_put_be32(struct sk
  */
 static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 value)
 {
-	return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+	__be32 tmp = value;
+
+	return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
 }
 
 /**
@@ -844,7 +861,9 @@ static inline int nla_put_net32(struct s
  */
 static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value)
 {
-	return nla_put(skb, attrtype, sizeof(__le32), &value);
+	__le32 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(__le32), &tmp);
 }
 
 /**
@@ -857,7 +876,9 @@ static inline int nla_put_le32(struct sk
 static inline int nla_put_u64_64bit(struct sk_buff *skb, int attrtype,
 				    u64 value, int padattr)
 {
-	return nla_put_64bit(skb, attrtype, sizeof(u64), &value, padattr);
+	u64 tmp = value;
+
+	return nla_put_64bit(skb, attrtype, sizeof(u64), &tmp, padattr);
 }
 
 /**
@@ -870,7 +891,9 @@ static inline int nla_put_u64_64bit(stru
 static inline int nla_put_be64(struct sk_buff *skb, int attrtype, __be64 value,
 			       int padattr)
 {
-	return nla_put_64bit(skb, attrtype, sizeof(__be64), &value, padattr);
+	__be64 tmp = value;
+
+	return nla_put_64bit(skb, attrtype, sizeof(__be64), &tmp, padattr);
 }
 
 /**
@@ -883,7 +906,9 @@ static inline int nla_put_be64(struct sk
 static inline int nla_put_net64(struct sk_buff *skb, int attrtype, __be64 value,
 				int padattr)
 {
-	return nla_put_be64(skb, attrtype | NLA_F_NET_BYTEORDER, value,
+	__be64 tmp = value;
+
+	return nla_put_be64(skb, attrtype | NLA_F_NET_BYTEORDER, tmp,
 			    padattr);
 }
 
@@ -897,7 +922,9 @@ static inline int nla_put_net64(struct s
 static inline int nla_put_le64(struct sk_buff *skb, int attrtype, __le64 value,
 			       int padattr)
 {
-	return nla_put_64bit(skb, attrtype, sizeof(__le64), &value, padattr);
+	__le64 tmp = value;
+
+	return nla_put_64bit(skb, attrtype, sizeof(__le64), &tmp, padattr);
 }
 
 /**
@@ -908,7 +935,9 @@ static inline int nla_put_le64(struct sk
  */
 static inline int nla_put_s8(struct sk_buff *skb, int attrtype, s8 value)
 {
-	return nla_put(skb, attrtype, sizeof(s8), &value);
+	s8 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(s8), &tmp);
 }
 
 /**
@@ -919,7 +948,9 @@ static inline int nla_put_s8(struct sk_b
  */
 static inline int nla_put_s16(struct sk_buff *skb, int attrtype, s16 value)
 {
-	return nla_put(skb, attrtype, sizeof(s16), &value);
+	s16 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(s16), &tmp);
 }
 
 /**
@@ -930,7 +961,9 @@ static inline int nla_put_s16(struct sk_
  */
 static inline int nla_put_s32(struct sk_buff *skb, int attrtype, s32 value)
 {
-	return nla_put(skb, attrtype, sizeof(s32), &value);
+	s32 tmp = value;
+
+	return nla_put(skb, attrtype, sizeof(s32), &tmp);
 }
 
 /**
@@ -943,7 +976,9 @@ static inline int nla_put_s32(struct sk_
 static inline int nla_put_s64(struct sk_buff *skb, int attrtype, s64 value,
 			      int padattr)
 {
-	return nla_put_64bit(skb, attrtype, sizeof(s64), &value, padattr);
+	s64 tmp = value;
+
+	return nla_put_64bit(skb, attrtype, sizeof(s64), &tmp, padattr);
 }
 
 /**
@@ -993,7 +1028,9 @@ static inline int nla_put_msecs(struct s
 static inline int nla_put_in_addr(struct sk_buff *skb, int attrtype,
 				  __be32 addr)
 {
-	return nla_put_be32(skb, attrtype, addr);
+	__be32 tmp = addr;
+
+	return nla_put_be32(skb, attrtype, tmp);
 }
 
 /**
maintainer
#90 lore raw

Re: [PATCH 4.9 090/105] netlink: fix nla_put_{u8,u16,u32} for KASAN

Quoted 14 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

commit b4391db42308c9940944b5d7be5ca4b78fb88dd0 upstream.

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y").

Quoted 7 lines

The kernelci.org build bot however has the warning enabled and that led me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Finally a clean build with kernelci again after a year of seeing this warning, thanks
for the backport!

Now I just need to find a fix for the spurious build failure when building objtool.

Arnd

author maintainer
#91 lore raw

PATCH 91/105 iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Luca Coelho <[email protected]>

commit 97bce57bd7f96e1218751996f549a6e61f18cc8c upstream.

The MCAST_FILTER_CMD can get quite large when we have many mcast addresses to set (we support up to 255). So the command should be send as NOCOPY to prevent a warning caused by too-long commands:

WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]

Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743

---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +9 -1
@@ -1548,6 +1548,11 @@ static void iwl_mvm_mc_iface_iterator(vo
 	struct iwl_mvm_mc_iter_data *data = _data;
 	struct iwl_mvm *mvm = data->mvm;
 	struct iwl_mcast_filter_cmd *cmd = mvm->mcast_filter_cmd;
+	struct iwl_host_cmd hcmd = {
+		.id = MCAST_FILTER_CMD,
+		.flags = CMD_ASYNC,
+		.dataflags[0] = IWL_HCMD_DFL_NOCOPY,
+	};
 	int ret, len;
 
 	/* if we don't have free ports, mcast frames will be dropped */
@@ -1562,7 +1567,10 @@ static void iwl_mvm_mc_iface_iterator(vo
 	memcpy(cmd->bssid, vif->bss_conf.bssid, ETH_ALEN);
 	len = roundup(sizeof(*cmd) + cmd->count * ETH_ALEN, 4);
 
-	ret = iwl_mvm_send_cmd_pdu(mvm, MCAST_FILTER_CMD, CMD_ASYNC, len, cmd);
+	hcmd.len[0] = len;
+	hcmd.data[0] = cmd;
+
+	ret = iwl_mvm_send_cmd(mvm, &hcmd);
 	if (ret)
 		IWL_ERR(mvm, "mcast filter cmd error. ret=%d\n", ret);
 }
author maintainer
#92 lore raw

PATCH 92/105 iwlwifi: add workaround to disable wide channels in 5GHz

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Luca Coelho <[email protected]>

commit 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels in the 5.2GHz band. The firmware has been modified to not allow this in those SKUs, so the driver needs to do the same otherwise the firmware will assert when we try to use it.

---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c |   66 +++++++++++++++++----
 1 file changed, 55 insertions(+), 11 deletions(-)
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c +55 -11
@@ -78,6 +78,7 @@
 /* NVM offsets (in words) definitions */
 enum wkp_nvm_offsets {
 	/* NVM HW-Section offset (in words) definitions */
+	SUBSYSTEM_ID = 0x0A,
 	HW_ADDR = 0x15,
 
 	/* NVM SW-Section offset (in words) definitions */
@@ -262,13 +263,12 @@ static u32 iwl_get_channel_flags(u8 ch_n
 static int iwl_init_channel_map(struct device *dev, const struct iwl_cfg *cfg,
 				struct iwl_nvm_data *data,
 				const __le16 * const nvm_ch_flags,
-				bool lar_supported)
+				bool lar_supported, bool no_wide_in_5ghz)
 {
 	int ch_idx;
 	int n_channels = 0;
 	struct ieee80211_channel *channel;
 	u16 ch_flags;
-	bool is_5ghz;
 	int num_of_ch, num_2ghz_channels;
 	const u8 *nvm_chan;
 
@@ -283,12 +283,20 @@ static int iwl_init_channel_map(struct d
 	}
 
 	for (ch_idx = 0; ch_idx < num_of_ch; ch_idx++) {
+		bool is_5ghz = (ch_idx >= num_2ghz_channels);
+
 		ch_flags = __le16_to_cpup(nvm_ch_flags + ch_idx);
 
-		if (ch_idx >= num_2ghz_channels &&
-		    !data->sku_cap_band_52GHz_enable)
+		if (is_5ghz && !data->sku_cap_band_52GHz_enable)
 			continue;
 
+		/* workaround to disable wide channels in 5GHz */
+		if (no_wide_in_5ghz && is_5ghz) {
+			ch_flags &= ~(NVM_CHANNEL_40MHZ |
+				     NVM_CHANNEL_80MHZ |
+				     NVM_CHANNEL_160MHZ);
+		}
+
 		if (ch_flags & NVM_CHANNEL_160MHZ)
 			data->vht160_supported = true;
 
@@ -311,8 +319,8 @@ static int iwl_init_channel_map(struct d
 		n_channels++;
 
 		channel->hw_value = nvm_chan[ch_idx];
-		channel->band = (ch_idx < num_2ghz_channels) ?
-				NL80211_BAND_2GHZ : NL80211_BAND_5GHZ;
+		channel->band = is_5ghz ?
+				NL80211_BAND_5GHZ : NL80211_BAND_2GHZ;
 		channel->center_freq =
 			ieee80211_channel_to_frequency(
 				channel->hw_value, channel->band);
@@ -324,7 +332,6 @@ static int iwl_init_channel_map(struct d
 		 * is not used in mvm, and is used for backwards compatibility
 		 */
 		channel->max_power = IWL_DEFAULT_MAX_TX_POWER;
-		is_5ghz = channel->band == NL80211_BAND_5GHZ;
 
 		/* don't put limitations in case we're using LAR */
 		if (!lar_supported)
@@ -441,7 +448,8 @@ static void iwl_init_vht_hw_capab(const
 static void iwl_init_sbands(struct device *dev, const struct iwl_cfg *cfg,
 			    struct iwl_nvm_data *data,
 			    const __le16 *ch_section,
-			    u8 tx_chains, u8 rx_chains, bool lar_supported)
+			    u8 tx_chains, u8 rx_chains, bool lar_supported,
+			    bool no_wide_in_5ghz)
 {
 	int n_channels;
 	int n_used = 0;
@@ -450,12 +458,14 @@ static void iwl_init_sbands(struct devic
 	if (cfg->device_family != IWL_DEVICE_FAMILY_8000)
 		n_channels = iwl_init_channel_map(
 				dev, cfg, data,
-				&ch_section[NVM_CHANNELS], lar_supported);
+				&ch_section[NVM_CHANNELS], lar_supported,
+				no_wide_in_5ghz);
 	else
 		n_channels = iwl_init_channel_map(
 				dev, cfg, data,
 				&ch_section[NVM_CHANNELS_FAMILY_8000],
-				lar_supported);
+				lar_supported,
+				no_wide_in_5ghz);
 
 	sband = &data->bands[NL80211_BAND_2GHZ];
 	sband->band = NL80211_BAND_2GHZ;
@@ -658,6 +668,39 @@ static int iwl_set_hw_address(struct iwl
 	return 0;
 }
 
+static bool
+iwl_nvm_no_wide_in_5ghz(struct device *dev, const struct iwl_cfg *cfg,
+			const __le16 *nvm_hw)
+{
+	/*
+	 * Workaround a bug in Indonesia SKUs where the regulatory in
+	 * some 7000-family OTPs erroneously allow wide channels in
+	 * 5GHz.  To check for Indonesia, we take the SKU value from
+	 * bits 1-4 in the subsystem ID and check if it is either 5 or
+	 * 9.  In those cases, we need to force-disable wide channels
+	 * in 5GHz otherwise the FW will throw a sysassert when we try
+	 * to use them.
+	 */
+	if (cfg->device_family == IWL_DEVICE_FAMILY_7000) {
+		/*
+		 * Unlike the other sections in the NVM, the hw
+		 * section uses big-endian.
+		 */
+		u16 subsystem_id = be16_to_cpup((const __be16 *)nvm_hw
+						+ SUBSYSTEM_ID);
+		u8 sku = (subsystem_id & 0x1e) >> 1;
+
+		if (sku == 5 || sku == 9) {
+			IWL_DEBUG_EEPROM(dev,
+					 "disabling wide channels in 5GHz (0x%0x %d)\n",
+					 subsystem_id, sku);
+			return true;
+		}
+	}
+
+	return false;
+}
+
 struct iwl_nvm_data *
 iwl_parse_nvm_data(struct iwl_trans *trans, const struct iwl_cfg *cfg,
 		   const __le16 *nvm_hw, const __le16 *nvm_sw,
@@ -668,6 +711,7 @@ iwl_parse_nvm_data(struct iwl_trans *tra
 	struct device *dev = trans->dev;
 	struct iwl_nvm_data *data;
 	bool lar_enabled;
+	bool no_wide_in_5ghz = iwl_nvm_no_wide_in_5ghz(dev, cfg, nvm_hw);
 	u32 sku, radio_cfg;
 	u16 lar_config;
 	const __le16 *ch_section;
@@ -738,7 +782,7 @@ iwl_parse_nvm_data(struct iwl_trans *tra
 	}
 
 	iwl_init_sbands(dev, cfg, data, ch_section, tx_chains, rx_chains,
-			lar_fw_supported && lar_enabled);
+			lar_fw_supported && lar_enabled, no_wide_in_5ghz);
 	data->calib_version = 255;
 
 	return data;
author maintainer
#93 lore raw

PATCH 93/105 scsi: sd: Do not override max_sectors_kb sysfs setting

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Martin K. Petersen <[email protected]>

commit 77082ca503bed061f7fbda7cfd7c93beda967a41 upstream.

A user may lower the max_sectors_kb setting in sysfs to accommodate certain workloads. Previously we would always set the max I/O size to either the block layer default or the optional preferred I/O size reported by the device.

Keep the current heuristics for the initial setting of max_sectors_kb. For subsequent invocations, only update the current queue limit if it exceeds the capabilities of the hardware.

---
 drivers/scsi/sd.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/scsi/sd.c +14 -5
@@ -2867,8 +2867,6 @@ static int sd_revalidate_disk(struct gen
 		sd_read_write_same(sdkp, buffer);
 	}
 
-	sdkp->first_scan = 0;
-
 	/*
 	 * We now have all cache related info, determine how we deal
 	 * with flush requests.
@@ -2883,7 +2881,7 @@ static int sd_revalidate_disk(struct gen
 	q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
 
 	/*
-	 * Use the device's preferred I/O size for reads and writes
+	 * Determine the device's preferred I/O size for reads and writes
 	 * unless the reported value is unreasonably small, large, or
 	 * garbage.
 	 */
@@ -2897,8 +2895,19 @@ static int sd_revalidate_disk(struct gen
 		rw_max = min_not_zero(logical_to_sectors(sdp, dev_max),
 				      (sector_t)BLK_DEF_MAX_SECTORS);
 
-	/* Combine with controller limits */
-	q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q));
+	/* Do not exceed controller limit */
+	rw_max = min(rw_max, queue_max_hw_sectors(q));
+
+	/*
+	 * Only update max_sectors if previously unset or if the current value
+	 * exceeds the capabilities of the hardware.
+	 */
+	if (sdkp->first_scan ||
+	    q->limits.max_sectors > q->limits.max_dev_sectors ||
+	    q->limits.max_sectors > q->limits.max_hw_sectors)
+		q->limits.max_sectors = rw_max;
+
+	sdkp->first_scan = 0;
 
 	set_capacity(disk, logical_to_sectors(sdp, sdkp->capacity));
 	sd_config_write_same(sdkp);
author maintainer
#94 lore raw

PATCH 94/105 brcmfmac: add length check in brcmf_cfg80211_escan_handler()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arend Van Spriel <[email protected]>

commit 17df6453d4be17910456e99c5a85025aa1b7a246 upstream.

Upon handling the firmware notification for scans the length was checked properly and may result in corrupting kernel heap memory due to buffer overruns. This fix addresses CVE-2017-0786.

---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c |   18 ++++++++++--
 1 file changed, 15 insertions(+), 3 deletions(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +15 -3
@@ -3097,6 +3097,7 @@ brcmf_cfg80211_escan_handler(struct brcm
 	struct brcmf_cfg80211_info *cfg = ifp->drvr->config;
 	s32 status;
 	struct brcmf_escan_result_le *escan_result_le;
+	u32 escan_buflen;
 	struct brcmf_bss_info_le *bss_info_le;
 	struct brcmf_bss_info_le *bss = NULL;
 	u32 bi_length;
@@ -3113,11 +3114,23 @@ brcmf_cfg80211_escan_handler(struct brcm
 
 	if (status == BRCMF_E_STATUS_PARTIAL) {
 		brcmf_dbg(SCAN, "ESCAN Partial result\n");
+		if (e->datalen < sizeof(*escan_result_le)) {
+			brcmf_err("invalid event data length\n");
+			goto exit;
+		}
 		escan_result_le = (struct brcmf_escan_result_le *) data;
 		if (!escan_result_le) {
 			brcmf_err("Invalid escan result (NULL pointer)\n");
 			goto exit;
 		}
+		escan_buflen = le32_to_cpu(escan_result_le->buflen);
+		if (escan_buflen > BRCMF_ESCAN_BUF_SIZE ||
+		    escan_buflen > e->datalen ||
+		    escan_buflen < sizeof(*escan_result_le)) {
+			brcmf_err("Invalid escan buffer length: %d\n",
+				  escan_buflen);
+			goto exit;
+		}
 		if (le16_to_cpu(escan_result_le->bss_count) != 1) {
 			brcmf_err("Invalid bss_count %d: ignoring\n",
 				  escan_result_le->bss_count);
@@ -3134,9 +3147,8 @@ brcmf_cfg80211_escan_handler(struct brcm
 		}
 
 		bi_length = le32_to_cpu(bss_info_le->length);
-		if (bi_length != (le32_to_cpu(escan_result_le->buflen) -
-					WL_ESCAN_RESULTS_FIXED_SIZE)) {
-			brcmf_err("Invalid bss_info length %d: ignoring\n",
+		if (bi_length != escan_buflen -	WL_ESCAN_RESULTS_FIXED_SIZE) {
+			brcmf_err("Ignoring invalid bss_info length: %d\n",
 				  bi_length);
 			goto exit;
 		}
author maintainer
#95 lore raw

PATCH 95/105 brcmfmac: setup passive scan if requested by user-space

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arend Van Spriel <[email protected]>

commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the type of scan. It always performed an active scan even when user-space was requesting for passive scan, ie. the scan request was done without any SSIDs specified.

---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c   |   19 ++--------
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h |    5 ++
 2 files changed, 9 insertions(+), 15 deletions(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +4 -15
@@ -978,7 +978,7 @@ static void brcmf_escan_prep(struct brcm
 
 	eth_broadcast_addr(params_le->bssid);
 	params_le->bss_type = DOT11_BSSTYPE_ANY;
-	params_le->scan_type = 0;
+	params_le->scan_type = BRCMF_SCANTYPE_ACTIVE;
 	params_le->channel_num = 0;
 	params_le->nprobes = cpu_to_le32(-1);
 	params_le->active_time = cpu_to_le32(-1);
@@ -986,12 +986,9 @@ static void brcmf_escan_prep(struct brcm
 	params_le->home_time = cpu_to_le32(-1);
 	memset(&params_le->ssid_le, 0, sizeof(params_le->ssid_le));
 
-	/* if request is null exit so it will be all channel broadcast scan */
-	if (!request)
-		return;
-
 	n_ssids = request->n_ssids;
 	n_channels = request->n_channels;
+
 	/* Copy channel array if applicable */
 	brcmf_dbg(SCAN, "### List of channelspecs to scan ### %d\n",
 		  n_channels);
@@ -1028,16 +1025,8 @@ static void brcmf_escan_prep(struct brcm
 			ptr += sizeof(ssid_le);
 		}
 	} else {
-		brcmf_dbg(SCAN, "Broadcast scan %p\n", request->ssids);
-		if ((request->ssids) && request->ssids->ssid_len) {
-			brcmf_dbg(SCAN, "SSID %s len=%d\n",
-				  params_le->ssid_le.SSID,
-				  request->ssids->ssid_len);
-			params_le->ssid_le.SSID_len =
-				cpu_to_le32(request->ssids->ssid_len);
-			memcpy(&params_le->ssid_le.SSID, request->ssids->ssid,
-				request->ssids->ssid_len);
-		}
+		brcmf_dbg(SCAN, "Performing passive scan\n");
+		params_le->scan_type = BRCMF_SCANTYPE_PASSIVE;
 	}
 	/* Adding mask to channel numbers */
 	params_le->channel_num =
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h +5 -0
@@ -45,6 +45,11 @@
 #define BRCMF_SCAN_PARAMS_COUNT_MASK	0x0000ffff
 #define BRCMF_SCAN_PARAMS_NSSID_SHIFT	16
 
+/* scan type definitions */
+#define BRCMF_SCANTYPE_DEFAULT		0xFF
+#define BRCMF_SCANTYPE_ACTIVE		0
+#define BRCMF_SCANTYPE_PASSIVE		1
+
 /* primary (ie tx) key */
 #define BRCMF_PRIMARY_KEY		(1 << 1)
 #define DOT11_BSSTYPE_ANY		2
author maintainer
#96 lore raw

PATCH 97/105 nvme-pci: Use PCI bus address for data/queues in CMB

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christoph Hellwig <[email protected]>

commit 8969f1f8291762c13147c1ba89d46238af01675b upstream.

Currently, NVMe PCI host driver is programming CMB dma address as I/O SQs addresses. This results in failures on systems where 1:1 outbound mapping is not used (example Broadcom iProc SOCs) because CMB BAR will be progammed with PCI bus address but NVMe PCI EP will try to access CMB using dma address.

To have CMB working on systems without 1:1 outbound mapping, we program PCI bus address for I/O SQs instead of dma address. This approach will work on systems with/without 1:1 outbound mapping.

Based on a report and previous patch from Abhishek Shah.

Fixes 8ffaadf7 ("NVMe: Use CMB for the IO SQes if available")
---
 drivers/nvme/host/pci.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/nvme/host/pci.c +7 -7
@@ -96,7 +96,7 @@ struct nvme_dev {
 	struct mutex shutdown_lock;
 	bool subsystem;
 	void __iomem *cmb;
-	dma_addr_t cmb_dma_addr;
+	pci_bus_addr_t cmb_bus_addr;
 	u64 cmb_size;
 	u32 cmbsz;
 	u32 cmbloc;
@@ -1037,7 +1037,7 @@ static int nvme_alloc_sq_cmds(struct nvm
 	if (qid && dev->cmb && use_cmb_sqes && NVME_CMB_SQS(dev->cmbsz)) {
 		unsigned offset = (qid - 1) * roundup(SQ_SIZE(depth),
 						      dev->ctrl.page_size);
-		nvmeq->sq_dma_addr = dev->cmb_dma_addr + offset;
+		nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset;
 		nvmeq->sq_cmds_io = dev->cmb + offset;
 	} else {
 		nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth),
@@ -1343,7 +1343,7 @@ static void __iomem *nvme_map_cmb(struct
 	resource_size_t bar_size;
 	struct pci_dev *pdev = to_pci_dev(dev->dev);
 	void __iomem *cmb;
-	dma_addr_t dma_addr;
+	int bar;
 
 	dev->cmbsz = readl(dev->bar + NVME_REG_CMBSZ);
 	if (!(NVME_CMB_SZ(dev->cmbsz)))
@@ -1356,7 +1356,8 @@ static void __iomem *nvme_map_cmb(struct
 	szu = (u64)1 << (12 + 4 * NVME_CMB_SZU(dev->cmbsz));
 	size = szu * NVME_CMB_SZ(dev->cmbsz);
 	offset = szu * NVME_CMB_OFST(dev->cmbloc);
-	bar_size = pci_resource_len(pdev, NVME_CMB_BIR(dev->cmbloc));
+	bar = NVME_CMB_BIR(dev->cmbloc);
+	bar_size = pci_resource_len(pdev, bar);
 
 	if (offset > bar_size)
 		return NULL;
@@ -1369,12 +1370,11 @@ static void __iomem *nvme_map_cmb(struct
 	if (size > bar_size - offset)
 		size = bar_size - offset;
 
-	dma_addr = pci_resource_start(pdev, NVME_CMB_BIR(dev->cmbloc)) + offset;
-	cmb = ioremap_wc(dma_addr, size);
+	cmb = ioremap_wc(pci_resource_start(pdev, bar) + offset, size);
 	if (!cmb)
 		return NULL;
 
-	dev->cmb_dma_addr = dma_addr;
+	dev->cmb_bus_addr = pci_bus_address(pdev, bar) + offset;
 	dev->cmb_size = size;
 	return cmb;
 }
author maintainer
#97 lore raw

PATCH 98/105 mmc: core: add driver strength selection when selecting hs400es

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Chanho Min <[email protected]>

commit fb458864d9a78cc433fec7979acbe4078c82d7a8 upstream.

The driver strength selection is missed and required when selecting hs400es. So, It is added here.

Fixes 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
---
 drivers/mmc/core/mmc.c |   36 +++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 17 deletions(-)
drivers/mmc/core/mmc.c +19 -17
@@ -1255,6 +1255,23 @@ out_err:
 	return err;
 }
 
+static void mmc_select_driver_type(struct mmc_card *card)
+{
+	int card_drv_type, drive_strength, drv_type;
+
+	card_drv_type = card->ext_csd.raw_driver_strength |
+			mmc_driver_type_mask(0);
+
+	drive_strength = mmc_select_drive_strength(card,
+						   card->ext_csd.hs200_max_dtr,
+						   card_drv_type, &drv_type);
+
+	card->drive_strength = drive_strength;
+
+	if (drv_type)
+		mmc_set_driver_type(card->host, drv_type);
+}
+
 static int mmc_select_hs400es(struct mmc_card *card)
 {
 	struct mmc_host *host = card->host;
@@ -1303,6 +1320,8 @@ static int mmc_select_hs400es(struct mmc
 		goto out_err;
 	}
 
+	mmc_select_driver_type(card);
+
 	/* Switch card to HS400 */
 	val = EXT_CSD_TIMING_HS400 |
 	      card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
@@ -1336,23 +1355,6 @@ out_err:
 	return err;
 }
 
-static void mmc_select_driver_type(struct mmc_card *card)
-{
-	int card_drv_type, drive_strength, drv_type;
-
-	card_drv_type = card->ext_csd.raw_driver_strength |
-			mmc_driver_type_mask(0);
-
-	drive_strength = mmc_select_drive_strength(card,
-						   card->ext_csd.hs200_max_dtr,
-						   card_drv_type, &drv_type);
-
-	card->drive_strength = drive_strength;
-
-	if (drv_type)
-		mmc_set_driver_type(card->host, drv_type);
-}
-
 /*
  * For device supporting HS200 mode, the following sequence
  * should be done before executing the tuning process.
author maintainer
#98 lore raw

PATCH 99/105 sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Zijlstra <[email protected]>

commit 50e76632339d4655859523a39249dd95ee5e93e7 upstream.

Cpusets vs. suspend-resume is _completely_ broken. And it got noticed because it now resulted in non-cpuset usage breaking too.

On suspend cpuset_cpu_inactive() doesn't call into cpuset_update_active_cpus() because it doesn't want to move tasks about, there is no need, all tasks are frozen and won't run again until after we've resumed everything.

But this means that when we finally do call into cpuset_update_active_cpus() after resuming the last frozen cpu in cpuset_cpu_active(), the top_cpuset will not have any difference with the cpu_active_mask and this it will not in fact do _anything_.

So the cpuset configuration will not be restored. This was largely hidden because we would unconditionally create identity domains and mobile users would not in fact use cpusets much. And servers what do use cpusets tend to not suspend-resume much.

An addition problem is that we'd not in fact wait for the cpuset work to finish before resuming the tasks, allowing spurious migrations outside of the specified domains.

Fix the rebuild by introducing cpuset_force_rebuild() and fix the ordering with cpuset_wait_for_hotplug().

Cc Andy Lutomirski <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Mike Galbraith <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Rafael J. Wysocki <[email protected]>
Cc Tejun Heo <[email protected]>
Cc Thomas Gleixner <[email protected]>
Fixes deb7aa308ea2 ("cpuset: reorganize CPU / memory hotplug handling")
---
 include/linux/cpuset.h |    6 ++++++
 kernel/cpuset.c        |   16 +++++++++++++++-
 kernel/power/process.c |    5 ++++-
 kernel/sched/core.c    |    7 +++----
 4 files changed, 28 insertions(+), 6 deletions(-)
include/linux/cpuset.h +6 -0
@@ -55,7 +55,9 @@ static inline void cpuset_dec(void)
 
 extern int cpuset_init(void);
 extern void cpuset_init_smp(void);
+extern void cpuset_force_rebuild(void);
 extern void cpuset_update_active_cpus(bool cpu_online);
+extern void cpuset_wait_for_hotplug(void);
 extern void cpuset_cpus_allowed(struct task_struct *p, struct cpumask *mask);
 extern void cpuset_cpus_allowed_fallback(struct task_struct *p);
 extern nodemask_t cpuset_mems_allowed(struct task_struct *p);
@@ -168,11 +170,15 @@ static inline bool cpusets_enabled(void)
 static inline int cpuset_init(void) { return 0; }
 static inline void cpuset_init_smp(void) {}
 
+static inline void cpuset_force_rebuild(void) { }
+
 static inline void cpuset_update_active_cpus(bool cpu_online)
 {
 	partition_sched_domains(1, NULL, NULL);
 }
 
+static inline void cpuset_wait_for_hotplug(void) { }
+
 static inline void cpuset_cpus_allowed(struct task_struct *p,
 				       struct cpumask *mask)
 {
kernel/cpuset.c +15 -1
@@ -2276,6 +2276,13 @@ retry:
 	mutex_unlock(&cpuset_mutex);
 }
 
+static bool force_rebuild;
+
+void cpuset_force_rebuild(void)
+{
+	force_rebuild = true;
+}
+
 /**
  * cpuset_hotplug_workfn - handle CPU/memory hotunplug for a cpuset
  *
@@ -2350,8 +2357,10 @@ static void cpuset_hotplug_workfn(struct
 	}
 
 	/* rebuild sched domains if cpus_allowed has changed */
-	if (cpus_updated)
+	if (cpus_updated || force_rebuild) {
+		force_rebuild = false;
 		rebuild_sched_domains();
+	}
 }
 
 void cpuset_update_active_cpus(bool cpu_online)
@@ -2370,6 +2379,11 @@ void cpuset_update_active_cpus(bool cpu_
 	schedule_work(&cpuset_hotplug_work);
 }
 
+void cpuset_wait_for_hotplug(void)
+{
+	flush_work(&cpuset_hotplug_work);
+}
+
 /*
  * Keep top_cpuset.mems_allowed tracking node_states[N_MEMORY].
  * Call this routine anytime after node_states[N_MEMORY] changes.
kernel/power/process.c +4 -1
@@ -18,8 +18,9 @@
 #include <linux/workqueue.h>
 #include <linux/kmod.h>
 #include <trace/events/power.h>
+#include <linux/cpuset.h>
 
-/* 
+/*
  * Timeout for stopping processes
  */
 unsigned int __read_mostly freeze_timeout_msecs = 20 * MSEC_PER_SEC;
@@ -200,6 +201,8 @@ void thaw_processes(void)
 	__usermodehelper_set_disable_depth(UMH_FREEZING);
 	thaw_workqueues();
 
+	cpuset_wait_for_hotplug();
+
 	read_lock(&tasklist_lock);
 	for_each_process_thread(g, p) {
 		/* No other threads should have PF_SUSPEND_TASK set */
kernel/sched/core.c +3 -4
@@ -7292,16 +7292,15 @@ static void cpuset_cpu_active(void)
 		 * operation in the resume sequence, just build a single sched
 		 * domain, ignoring cpusets.
 		 */
-		num_cpus_frozen--;
-		if (likely(num_cpus_frozen)) {
-			partition_sched_domains(1, NULL, NULL);
+		partition_sched_domains(1, NULL, NULL);
+		if (--num_cpus_frozen)
 			return;
-		}
 		/*
 		 * This is the last CPU online operation. So fall through and
 		 * restore the original sched domains by considering the
 		 * cpuset configurations.
 		 */
+		cpuset_force_rebuild();
 	}
 	cpuset_update_active_cpus(true);
 }
author maintainer
#99 lore raw

PATCH 100/105 vfs: deny copy_file_range() for non regular files

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Amir Goldstein <[email protected]>

commit 11cbfb10775aa2a01cee966d118049ede9d0bdf2 upstream.

There is no in-tree file system that implements copy_file_range() for non regular files.

Deny an attempt to copy_file_range() a directory with EISDIR and any other non regualr file with EINVAL to conform with behavior of vfs_{clone,dedup}_file_range().

This change is needed prior to converting sb_start_write() to file_start_write() in the vfs helper.

---
 fs/read_write.c |    5 +++++
 1 file changed, 5 insertions(+)
fs/read_write.c +5 -0
@@ -1518,6 +1518,11 @@ ssize_t vfs_copy_file_range(struct file
 	if (flags != 0)
 		return -EINVAL;
 
+	if (S_ISDIR(inode_in->i_mode) || S_ISDIR(inode_out->i_mode))
+		return -EISDIR;
+	if (!S_ISREG(inode_in->i_mode) || !S_ISREG(inode_out->i_mode))
+		return -EINVAL;
+
 	ret = rw_verify_area(READ, file_in, &pos_in, len);
 	if (unlikely(ret))
 		return ret;
author maintainer
#100 lore raw

PATCH 101/105 ext4: fix data corruption for mmap writes

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kara <[email protected]>

commit a056bdaae7a181f7dcc876cfab2f94538e508709 upstream.

mpage_submit_page() can race with another process growing i_size and writing data via mmap to the written-back page. As mpage_submit_page() samples i_size too early, it may happen that ext4_bio_write_page() zeroes out too large tail of the page and thus corrupts user data.

Fix the problem by sampling i_size only after the page has been write-protected in page tables by clear_page_dirty_for_io() call.

Fixes cb20d5188366f04d96d2e07b1240cc92170ade40
---
 fs/ext4/inode.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)
fs/ext4/inode.c +16 -2
@@ -2107,15 +2107,29 @@ static int ext4_writepage(struct page *p
 static int mpage_submit_page(struct mpage_da_data *mpd, struct page *page)
 {
 	int len;
-	loff_t size = i_size_read(mpd->inode);
+	loff_t size;
 	int err;
 
 	BUG_ON(page->index != mpd->first_page);
+	clear_page_dirty_for_io(page);
+	/*
+	 * We have to be very careful here!  Nothing protects writeback path
+	 * against i_size changes and the page can be writeably mapped into
+	 * page tables. So an application can be growing i_size and writing
+	 * data through mmap while writeback runs. clear_page_dirty_for_io()
+	 * write-protects our page in page tables and the page cannot get
+	 * written to again until we release page lock. So only after
+	 * clear_page_dirty_for_io() we are safe to sample i_size for
+	 * ext4_bio_write_page() to zero-out tail of the written page. We rely
+	 * on the barrier provided by TestClearPageDirty in
+	 * clear_page_dirty_for_io() to make sure i_size is really sampled only
+	 * after page tables are updated.
+	 */
+	size = i_size_read(mpd->inode);
 	if (page->index == size >> PAGE_SHIFT)
 		len = size & ~PAGE_MASK;
 	else
 		len = PAGE_SIZE;
-	clear_page_dirty_for_io(page);
 	err = ext4_bio_write_page(&mpd->io_submit, page, len, mpd->wbc, false);
 	if (!err)
 		mpd->wbc->nr_to_write--;
author maintainer
#101 lore raw

PATCH 102/105 ext4: Dont clear SGID when inheriting ACLs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kara <[email protected]>

commit a3bb2d5587521eea6dab2d05326abb0afb460abd upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of __ext4_set_acl() into ext4_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway.

Fixes 073931017b49d9458aa351605b43a7e34598caef
---
 fs/ext4/acl.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)
fs/ext4/acl.c +15 -7
@@ -192,13 +192,6 @@ __ext4_set_acl(handle_t *handle, struct
 	switch (type) {
 	case ACL_TYPE_ACCESS:
 		name_index = EXT4_XATTR_INDEX_POSIX_ACL_ACCESS;
-		if (acl) {
-			error = posix_acl_update_mode(inode, &inode->i_mode, &acl);
-			if (error)
-				return error;
-			inode->i_ctime = ext4_current_time(inode);
-			ext4_mark_inode_dirty(handle, inode);
-		}
 		break;
 
 	case ACL_TYPE_DEFAULT:
@@ -231,6 +224,8 @@ ext4_set_acl(struct inode *inode, struct
 {
 	handle_t *handle;
 	int error, retries = 0;
+	umode_t mode = inode->i_mode;
+	int update_mode = 0;
 
 retry:
 	handle = ext4_journal_start(inode, EXT4_HT_XATTR,
@@ -238,7 +233,20 @@ retry:
 	if (IS_ERR(handle))
 		return PTR_ERR(handle);
 
+	if ((type == ACL_TYPE_ACCESS) && acl) {
+		error = posix_acl_update_mode(inode, &mode, &acl);
+		if (error)
+			goto out_stop;
+		update_mode = 1;
+	}
+
 	error = __ext4_set_acl(handle, inode, type, acl);
+	if (!error && update_mode) {
+		inode->i_mode = mode;
+		inode->i_ctime = ext4_current_time(inode);
+		ext4_mark_inode_dirty(handle, inode);
+	}
+out_stop:
 	ext4_journal_stop(handle);
 	if (error == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries))
 		goto retry;
author maintainer
#102 lore raw

PATCH 103/105 ext4: dont allow encrypted operations without keys

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Theodore Ts'o <[email protected]>

commit 173b8439e1ba362007315868928bf9d26e5cc5a6 upstream.

While we allow deletes without the key, the following should not be permitted:

# cd /vdc/encrypted-dir-without-key
# ls -l
total 4
-rw-r--r-- 1 root root   0 Dec 27 22:35 6,LKNRJsp209FbXoSvJWzB
-rw-r--r-- 1 root root 286 Dec 27 22:35 uRJ5vJh9gE7vcomYMqTAyD
# mv uRJ5vJh9gE7vcomYMqTAyD  6,LKNRJsp209FbXoSvJWzB
---
 fs/ext4/namei.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
fs/ext4/namei.c +12 -0
@@ -3527,6 +3527,12 @@ static int ext4_rename(struct inode *old
 			EXT4_I(old_dentry->d_inode)->i_projid)))
 		return -EXDEV;
 
+	if ((ext4_encrypted_inode(old_dir) &&
+	     !fscrypt_has_encryption_key(old_dir)) ||
+	    (ext4_encrypted_inode(new_dir) &&
+	     !fscrypt_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	retval = dquot_initialize(old.dir);
 	if (retval)
 		return retval;
@@ -3726,6 +3732,12 @@ static int ext4_cross_rename(struct inod
 	u8 new_file_type;
 	int retval;
 
+	if ((ext4_encrypted_inode(old_dir) &&
+	     !fscrypt_has_encryption_key(old_dir)) ||
+	    (ext4_encrypted_inode(new_dir) &&
+	     !fscrypt_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	if ((ext4_encrypted_inode(old_dir) ||
 	     ext4_encrypted_inode(new_dir)) &&
 	    (old_dir != new_dir) &&
author maintainer
#103 lore raw

PATCH 104/105 f2fs: dont allow encrypted operations without keys

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jaegeuk Kim <[email protected]>

commit 363fa4e078cbdc97a172c19d19dc04b41b52ebc8 upstream.

This patch fixes the renaming bug on encrypted filenames, which was pointed by

(ext4: don't allow encrypted operations without keys)

---
 fs/f2fs/namei.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
fs/f2fs/namei.c +12 -0
@@ -663,6 +663,12 @@ static int f2fs_rename(struct inode *old
 	bool is_old_inline = f2fs_has_inline_dentry(old_dir);
 	int err = -ENOENT;
 
+	if ((f2fs_encrypted_inode(old_dir) &&
+			!fscrypt_has_encryption_key(old_dir)) ||
+			(f2fs_encrypted_inode(new_dir) &&
+			!fscrypt_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	if ((old_dir != new_dir) && f2fs_encrypted_inode(new_dir) &&
 			!fscrypt_has_permitted_context(new_dir, old_inode)) {
 		err = -EPERM;
@@ -843,6 +849,12 @@ static int f2fs_cross_rename(struct inod
 	int old_nlink = 0, new_nlink = 0;
 	int err = -ENOENT;
 
+	if ((f2fs_encrypted_inode(old_dir) &&
+			!fscrypt_has_encryption_key(old_dir)) ||
+			(f2fs_encrypted_inode(new_dir) &&
+			!fscrypt_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	if ((f2fs_encrypted_inode(old_dir) || f2fs_encrypted_inode(new_dir)) &&
 			(old_dir != new_dir) &&
 			(!fscrypt_has_permitted_context(new_dir, old_inode) ||
#104 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

thanks,
-- Shuah

author maintainer
#105 lore raw
Quoted 17 lines · Shuah Khan
Quoted 16 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

Quoted 8 lines
Quoted 2 lines

greg k-h

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

Thanks for testing this, and the other kernels as well.

greg k-h

#106 lore raw
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

Full bisect log below:

git bisect start
# good: [f37eb7b586f1dd24a86c50278c65322fc6787722] Linux 4.9.54
git bisect good f37eb7b586f1dd24a86c50278c65322fc6787722
# bad: [5baa6510b9c929682655869bb2de4c61677dba82] Linux 4.9.55-rc1
git bisect bad 5baa6510b9c929682655869bb2de4c61677dba82
# bad: [830e3de48a789f8d294a0d1461600f958afddde4] ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header git bisect bad 830e3de48a789f8d294a0d1461600f958afddde4
# good: [41351b19147c9d5000ba481bc74f7a99f3435229] xhci: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor git bisect good 41351b19147c9d5000ba481bc74f7a99f3435229
# good: [d1e7f7464056ce747a4d44df7edae2a6e6f6bf41] staging: vchiq_2835_arm: Fix NULL ptr dereference in free_pagelist git bisect good d1e7f7464056ce747a4d44df7edae2a6e6f6bf41
# good: [7ecbf6d9a504a91587628585f9b14e643ae72b00] mlxsw: spectrum: Prevent mirred-related crash on removal git bisect good 7ecbf6d9a504a91587628585f9b14e643ae72b00
# good: [98b958a5e07a6eb42c11af87b5fdf41feba4ecdb] tcp: update skb->skb_mstamp more carefully
git bisect good 98b958a5e07a6eb42c11af87b5fdf41feba4ecdb
# good: [face8c646b066afd53c4b8f356344bf7628df789] tcp: fix data delivery rate
git bisect good face8c646b066afd53c4b8f356344bf7628df789
# good: [747ffa1dfcffa8255c17b277ec2c954a2036fbd5] udpv6: Fix the checksum computation when HW checksum does not apply git bisect good 747ffa1dfcffa8255c17b277ec2c954a2036fbd5

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4] ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
author maintainer
#107 lore raw
Quoted 33 lines · Shuah Khan
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

Quoted 7 lines
# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

What is the symptom of the networking failure? No networking device? No dhcp request? ipv4 or ipv6? Differences in dmesg?

thanks,

greg k-h

author maintainer
#108 lore raw
Quoted 37 lines · Greg Kroah-Hartman
Quoted 36 lines · Shuah Khan
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
Quoted 7 lines
Quoted 4 lines

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

What is the symptom of the networking failure? No networking device? No dhcp request? ipv4 or ipv6? Differences in dmesg?

Hm, I'm getting an odd report from some of the google auto-builders about a networking issue as well with 4.9. So you might be onto something here. I really have no insight into the google tests to figure out what it is doing, but I can feed it patches to test, so I'll try reverting this patch to see if it solves anything or not...

thanks,

greg k-h

author maintainer
#109 lore raw
Quoted 43 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 40 lines · Shuah Khan
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

Quoted 8 lines
Quoted 2 lines

What is the symptom of the networking failure? No networking device? No dhcp request? ipv4 or ipv6? Differences in dmesg?

Hm, I'm getting an odd report from some of the google auto-builders about a networking issue as well with 4.9. So you might be onto something here. I really have no insight into the google tests to figure out what it is doing, but I can feed it patches to test, so I'll try reverting this patch to see if it solves anything or not...

Nope reverting that failed as well, I'm running out of time at the moment to test this, will be able to pick it back up later this evening or tomorrow, so any help you could provide here would be great.

thanks,

greg k-h

#110 lore raw
Quoted 39 lines · Greg Kroah-Hartman
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Greg Kroah-Hartman
Quoted 36 lines · Shuah Khan
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

What is the symptom of the networking failure? No networking device? No dhcp request? ipv4 or ipv6? Differences in dmesg?

No differences in dmesg. The interface reports it is up, however doesn't respond to ping. Network manager reports it down. I enabled and disabled the networking. That didn't bring it back. Doesn't happen on 4.9.54.

Quoted 11 lines
Quoted 6 lines

Hm, I'm getting an odd report from some of the google auto-builders about a networking issue as well with 4.9. So you might be onto something here. I really have no insight into the google tests to figure out what it is doing, but I can feed it patches to test, so I'll try reverting this patch to see if it solves anything or not...

Nope reverting that failed as well, I'm running out of time at the moment to test this, will be able to pick it back up later this evening or tomorrow, so any help you could provide here would be great.

I will do some controlled tests today. I will have to run through bisect again. There are other ipv6 related patches in this release. I will let you know what I can find. I don't think it is driver/hw related.

thanks,
-- Shuah

#111 lore raw
Quoted 45 lines · Shuah Khan
Quoted 44 lines · Greg Kroah-Hartman
Quoted 43 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 40 lines · Shuah Khan
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 5 lines

Compiled and booted. Networking is dead. I will bisect tomorrow and let you know what I find.

r8169 is the suspect perhaps or some other change that affects it. Anyway more on this tomorrow.

Odd, let me know if you find anything.

git bisect came up with the following:

# first bad commit: [830e3de48a789f8d294a0d1461600f958afddde4]
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header

However, reverting this commit didn't work either. I might have to start bisect again. Update for now in case David or Xin Long can think of something that could possibly lead this failure. There are a few more patches in this space.

Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

What is the symptom of the networking failure? No networking device? No dhcp request? ipv4 or ipv6? Differences in dmesg?

No differences in dmesg. The interface reports it is up, however doesn't respond to ping. Network manager reports it down. I enabled and disabled the networking. That didn't bring it back. Doesn't happen on 4.9.54.

I built and installed 4.9.55 in my kvm guest, and login with console, no ip address configured on the NIC by dhclient.

Then I do dhclient eth0, it showed:

# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Can't install packet filter program: Cannot allocate memory

Then after I configure ip address manually, it works well.

So pls check if the dhclient doesn't work either in you env.

Quoted 20 lines
Quoted 8 lines
Quoted 7 lines

Hm, I'm getting an odd report from some of the google auto-builders about a networking issue as well with 4.9. So you might be onto something here. I really have no insight into the google tests to figure out what it is doing, but I can feed it patches to test, so I'll try reverting this patch to see if it solves anything or not...

Quoted 4 lines

Nope reverting that failed as well, I'm running out of time at the moment to test this, will be able to pick it back up later this evening or tomorrow, so any help you could provide here would be great.

I will do some controlled tests today. I will have to run through bisect again. There are other ipv6 related patches in this release. I will let you know what I can find. I don't think it is driver/hw related.

thanks,
-- Shuah

#112 lore raw

Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error here:

Job for dhcpd4.service failed because the control process exited with error code.
See "systemctl status dhcpd4.service" and "journalctl -xe" for details.
root@server64:/root # systemctl status dhcpd4.service
● dhcpd4.service - IPv4 DHCP server
Loaded: loaded (/usr/lib/systemd/system/dhcpd4.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-10-12 17:09:38 CEST; 8s ago
Process: 638 ExecStart=/usr/bin/dhcpd -4 -q -user dhcp -cf /etc/dhcpd.conf -pf /run/dhcpd4.pid (code=exited, status=1/FAILURE)

Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.

journalctl -xe
Okt 12 17:09:37 server64 systemd[1]: Starting IPv4 DHCP server... -- Subject: Unit dhcpd4.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Signature · 28 lines
-- Unit dhcpd4.service has begun starting up.
Okt 12 17:09:38 server64 dhcpd[638]: Internet Systems Consortium DHCP Server 4.3.6
Okt 12 17:09:38 server64 dhcpd[638]: Copyright 2004-2017 Internet Systems Consortium.
Okt 12 17:09:38 server64 dhcpd[638]: All rights reserved.
Okt 12 17:09:38 server64 dhcpd[638]: For info, please visit https://www.isc.org/software/dhcp/
Okt 12 17:09:38 server64 dhcpd[638]: Source compiled to use binary-leases
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 deleted host decls to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 new dynamic host decls to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 16 leases to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Can't install packet filter program: Cannot allocate memory
Okt 12 17:09:38 server64 dhcpd[638]: 
Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather
Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting
Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file
Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug.  These pages explain the proper
Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging.
Okt 12 17:09:38 server64 dhcpd[638]: 
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'.
Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.
-- Subject: Unit dhcpd4.service has failed


All works well with version 4.9.54 here. Holding back 4.9.55 for now.

-Andy
Arch Linux
#113 lore raw
Quoted 41 lines · Andreas Radke

Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error here:

Job for dhcpd4.service failed because the control process exited with error code.
See "systemctl status dhcpd4.service" and "journalctl -xe" for details.
root@server64:/root # systemctl status dhcpd4.service
● dhcpd4.service - IPv4 DHCP server
Loaded: loaded (/usr/lib/systemd/system/dhcpd4.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-10-12 17:09:38 CEST; 8s ago
Process: 638 ExecStart=/usr/bin/dhcpd -4 -q -user dhcp -cf /etc/dhcpd.conf -pf /run/dhcpd4.pid (code=exited, status=1/FAILURE)

Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.

journalctl -xe
Okt 12 17:09:37 server64 systemd[1]: Starting IPv4 DHCP server...
-- Subject: Unit dhcpd4.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dhcpd4.service has begun starting up.
Okt 12 17:09:38 server64 dhcpd[638]: Internet Systems Consortium DHCP Server 4.3.6 Okt 12 17:09:38 server64 dhcpd[638]: Copyright 2004-2017 Internet Systems Consortium. Okt 12 17:09:38 server64 dhcpd[638]: All rights reserved.
Okt 12 17:09:38 server64 dhcpd[638]: For info, please visit https://www.isc.org/software/dhcp/
Okt 12 17:09:38 server64 dhcpd[638]: Source compiled to use binary-leases
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 deleted host decls to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 new dynamic host decls to leases file. Okt 12 17:09:38 server64 dhcpd[638]: Wrote 16 leases to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Can't install packet filter program: Cannot allocate memory Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file

Quoted 8 lines

Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.
-- Subject: Unit dhcpd4.service has failed

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 2 12:20:51 2017 -0700

socket, bpf: fix possible use after free

which caused a obvious issue in __sk_attach_prog():

        atomic_set(&fp->refcnt, 0);  <----

        if (!sk_filter_charge(sk, fp)) {
                kfree(fp);
                return -ENOMEM;
        }

bool sk_filter_charge(struct sock *sk, struct sk_filter *fp)

{
        if (!atomic_inc_not_zero(&fp->refcnt)) <----
                return false;

        if (!__sk_filter_charge(sk, fp)) {
                sk_filter_release(fp);
                return false;
        }
Quoted 6 lines

All works well with version 4.9.54 here. Holding back 4.9.55 for now.

-Andy
Arch Linux

#114 lore raw
Quoted 51 lines · Xin Long
Quoted 41 lines · Andreas Radke

Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error here:

Job for dhcpd4.service failed because the control process exited with error code.
See "systemctl status dhcpd4.service" and "journalctl -xe" for details.
root@server64:/root # systemctl status dhcpd4.service
● dhcpd4.service - IPv4 DHCP server
Loaded: loaded (/usr/lib/systemd/system/dhcpd4.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-10-12 17:09:38 CEST; 8s ago
Process: 638 ExecStart=/usr/bin/dhcpd -4 -q -user dhcp -cf /etc/dhcpd.conf -pf /run/dhcpd4.pid (code=exited, status=1/FAILURE)

Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.

journalctl -xe
Okt 12 17:09:37 server64 systemd[1]: Starting IPv4 DHCP server...
-- Subject: Unit dhcpd4.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dhcpd4.service has begun starting up.
Okt 12 17:09:38 server64 dhcpd[638]: Internet Systems Consortium DHCP Server 4.3.6 Okt 12 17:09:38 server64 dhcpd[638]: Copyright 2004-2017 Internet Systems Consortium. Okt 12 17:09:38 server64 dhcpd[638]: All rights reserved.
Okt 12 17:09:38 server64 dhcpd[638]: For info, please visit https://www.isc.org/software/dhcp/
Okt 12 17:09:38 server64 dhcpd[638]: Source compiled to use binary-leases
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 deleted host decls to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 new dynamic host decls to leases file. Okt 12 17:09:38 server64 dhcpd[638]: Wrote 16 leases to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Can't install packet filter program: Cannot allocate memory Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file

Quoted 8 lines

Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.
-- Subject: Unit dhcpd4.service has failed

Quoted 2 lines

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Correction. The commit is:

345c66695569db83eed100723e4df72cb54df7de

I will try the revert and let you know.

strace shows the following - clear ENOMEM

socket(AF_PACKET, SOCK_RAW, 768) = 5
ioctl(5, SIOCGIFINDEX, {ifr_name="eth0", }) = 0
bind(5, {sa_family=AF_PACKET, proto=0x03, if2, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
setsockopt(5, SOL_PACKET, PACKET_AUXDATA, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, "\v\0\0\0\0\0\0\0`\330\260\330\275U\0\0", 16) = -1 ENOMEM (Cannot allocate memory) sendto(3, "<27>Oct 12 09:23:46 dhclient[278"..., 95, MSG_NOSIGNAL, NULL, 0) = 95
write(2, "Can't install packet filter prog"..., 59Can't install packet filter program: Cannot allocate memory) = 59 write(2, "\n", 1
) = 1

thanks,
-- Shuah

Acked-by Alexei Starovoitov Acked-by Daniel Borkmann
#115 lore raw
Quoted 52 lines · Shuah Khan
Quoted 51 lines · Xin Long
Quoted 49 lines · Andreas Radke

Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error here:

Job for dhcpd4.service failed because the control process exited with error code.
See "systemctl status dhcpd4.service" and "journalctl -xe" for details.
root@server64:/root # systemctl status dhcpd4.service
● dhcpd4.service - IPv4 DHCP server
Loaded: loaded (/usr/lib/systemd/system/dhcpd4.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-10-12 17:09:38 CEST; 8s ago
Process: 638 ExecStart=/usr/bin/dhcpd -4 -q -user dhcp -cf /etc/dhcpd.conf -pf /run/dhcpd4.pid (code=exited, status=1/FAILURE)

Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.

journalctl -xe
Okt 12 17:09:37 server64 systemd[1]: Starting IPv4 DHCP server...
-- Subject: Unit dhcpd4.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dhcpd4.service has begun starting up.
Okt 12 17:09:38 server64 dhcpd[638]: Internet Systems Consortium DHCP Server 4.3.6 Okt 12 17:09:38 server64 dhcpd[638]: Copyright 2004-2017 Internet Systems Consortium. Okt 12 17:09:38 server64 dhcpd[638]: All rights reserved.
Okt 12 17:09:38 server64 dhcpd[638]: For info, please visit https://www.isc.org/software/dhcp/
Okt 12 17:09:38 server64 dhcpd[638]: Source compiled to use binary-leases
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 deleted host decls to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Wrote 0 new dynamic host decls to leases file. Okt 12 17:09:38 server64 dhcpd[638]: Wrote 16 leases to leases file.
Okt 12 17:09:38 server64 dhcpd[638]: Can't install packet filter program: Cannot allocate memory Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: If you think you have received this message due to a bug rather Okt 12 17:09:38 server64 dhcpd[638]: than a configuration issue please read the section on submitting Okt 12 17:09:38 server64 dhcpd[638]: bugs on either our web page at www.isc.org or in the README file Okt 12 17:09:38 server64 dhcpd[638]: before submitting a bug. These pages explain the proper Okt 12 17:09:38 server64 dhcpd[638]: process and the information we find helpful for debugging. Okt 12 17:09:38 server64 dhcpd[638]:
Okt 12 17:09:38 server64 dhcpd[638]: exiting.
Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Control process exited, code=exited status=1 Okt 12 17:09:38 server64 systemd[1]: dhcpd4.service: Failed with result 'exit-code'. Okt 12 17:09:38 server64 systemd[1]: Failed to start IPv4 DHCP server.
-- Subject: Unit dhcpd4.service has failed

Quoted 8 lines
Quoted 2 lines

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Correction. The commit is:

345c66695569db83eed100723e4df72cb54df7de

I will try the revert and let you know.

okay reverting the

commit 345c66695569db83eed100723e4df72cb54df7de

Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 2 12:20:51 2017 -0700

socket, bpf: fix possible use after free

[ Upstream commit eefca20eb20c66b06cf5ed09b49b1a7caaa27b7b ]

Starting from linux-4.4, 3WHS no longer takes the listener lock.

Since this time, we might hit a use-after-free in sk_filter_charge(), if the filter we got in the memcpy() of the listener content just happened to be replaced by a thread changing listener BPF filter.

To fix this, we need to make sure the filter refcount is not already zero before incrementing it again.

Fixes e994b2f0fb92 ("tcp: do not lock listener to process SYN packets")

fixes the issue. Looks like this is a fix for another problem.

Anyway - I have 4.9.55 - minus 345c66695569db83eed100723e4df72cb54df7de running now with networking operational.

thanks,
-- Shuah

#116 lore raw
Quoted 6 lines · Shuah Khan
Quoted 5 lines · Shuah Khan
Quoted 4 lines · Xin Long
Quoted 2 lines · Andreas Radke

Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error here:

[...]

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Okt 12 17:09:38 server64 dhcpd[638]: Can't install packet filter program: Cannot allocate memory

[...]

Quoted 19 lines
Quoted 8 lines
Quoted 2 lines

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Correction. The commit is:

345c66695569db83eed100723e4df72cb54df7de

I will try the revert and let you know.

okay reverting the

commit 345c66695569db83eed100723e4df72cb54df7de
Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 2 12:20:51 2017 -0700

    socket, bpf: fix possible use after free


    [ Upstream commit eefca20eb20c66b06cf5ed09b49b1a7caaa27b7b ]

[...]

Quoted 1 line

fixes the issue. Looks like this is a fix for another problem.

It seems to depend on:

commit 4c355cdfbba537971b5c3849680b1b6453a7a383
Author: Reshetova, Elena <[email protected]> Date:   Tue Mar 21 13:59:19 2017 +0200

    net: convert sk_filter.refcnt from atomic_t to refcount_t

That split up sk_filter_charge() so that the refcount initialisation won't trip the increment-from-zero check.

Ben.

Quoted 9 lines

Anyway - I have 4.9.55 - minus
345c66695569db83eed100723e4df72cb54df7de
running now with networking operational.

thanks,
-- Shuah

Signature · 2 lines
Ben Hutchings
Software Developer, Codethink Ltd.
#117 lore raw
In reply to Xin Long

From: Xin Long <[email protected]>
Date: Thu, 12 Oct 2017 23:25:10 +0800

Quoted 7 lines

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 2 12:20:51 2017 -0700

socket, bpf: fix possible use after free

Quoted 7 lines

which caused a obvious issue in __sk_attach_prog():

        atomic_set(&fp->refcnt, 0);  <----

        if (!sk_filter_charge(sk, fp)) {
                kfree(fp);
                return -ENOMEM;
        }

Yeah this is the bad patch, my backport was buggy.

Greg, please revert.

author maintainer
#118 lore raw
Quoted 13 lines · David Miller

From: Xin Long <[email protected]>
Date: Thu, 12 Oct 2017 23:25:10 +0800

Quoted 10 lines

pls try revert:
commit 02f7e4101092b88e57c73171174976c8a72a3eba

Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 2 12:20:51 2017 -0700

socket, bpf: fix possible use after free

which caused a obvious issue in __sk_attach_prog():

        atomic_set(&fp->refcnt, 0);  <----
Quoted 8 lines
Quoted 4 lines
        if (!sk_filter_charge(sk, fp)) {
                kfree(fp);
                return -ENOMEM;
        }

Yeah this is the bad patch, my backport was buggy.

Greg, please revert.

No problem, I'll go revert it now.

Thanks to everyone for the good debugging and quick response.

greg k-h

#119 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 123 pass: 123 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

#120 lore raw
In reply to Greg Kroah-Hartman
Quoted 17 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.55 release. There are 105 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 Thu Oct 12 19:24:56 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.55-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.9.y
and the diffstat can be found below.

Quoted 5 lines

thanks,

greg k-h

-

Results from Linaro’s test farm. Juno results are disappointingly unavailable and I’m not willing to hold up this info any longer to wait for it.

kernel: 4.9.55-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 5baa6510b9c929682655869bb2de4c61677dba82
git describe: v4.9.54-106-g5baa6510b9c9
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.54-106-g5baa6510b9c9

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 known failures (need ash added to test img)
* ltp-containers-tests - 71 pass - 10 known failures (triage in progress, veth0 needs to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 985 pass - 122 skip - 2 known failures
* ltp-timers-tests - 13 pass

x15 - arm
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (need ksh added to test img)
* ltp-containers-tests - 63 pass - 18 fail (being triaged)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 know failures (quota needs to be added to the test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 failures (needs to be triaged)
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1040 pass - 68 skip - 2 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 52 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 15 skip - 5 known failures (need to add ksh to test img)
* ltp-containers-tests - 63 pass - 18 failures (triage in progress, veth0 needs to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 8 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 963 pass - 163 skip - 11 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports