[PATCH 4.4 00/25] 4.4.52-stable review

[PATCH 4.4 00/25] 4.4.52-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.4.52 release.
There are 25 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 Sun Feb 26 08:21:10 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.4.52-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.52-rc1

Peter Chen <peter.chen@nxp.com>
    Revert "usb: chipidea: imx: enable CI_HDRC_SET_NON_ZERO_TTHA"

Michael Schenk <michael.schenk@albis-elcon.com>
    rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down

Tejun Heo <tj@kernel.org>
    block: fix double-free in the failure path of cgwb_bdi_init()

Thomas Gleixner <tglx@linutronix.de>
    goldfish: Sanitize the broken interrupt handler

Thomas Gleixner <tglx@linutronix.de>
    x86/platform/goldfish: Prevent unconditional loading

Johan Hovold <johan@kernel.org>
    USB: serial: ark3116: fix register-accessor error handling

Johan Hovold <johan@kernel.org>
    USB: serial: opticon: fix CTS retrieval at open

Johan Hovold <johan@kernel.org>
    USB: serial: spcp8x5: fix modem-status handling

Johan Hovold <johan@kernel.org>
    USB: serial: digi_acceleport: fix OOB data sanity check

Johan Hovold <johan@kernel.org>
    USB: serial: ftdi_sio: fix line-status over-reporting

Johan Hovold <johan@kernel.org>
    USB: serial: ftdi_sio: fix extreme low-latency setting

Johan Hovold <johan@kernel.org>
    USB: serial: ftdi_sio: fix modem-status error handling

Ken Lin <yungching0725@gmail.com>
    USB: serial: cp210x: add new IDs for GE Bx50v3 boards

Johan Hovold <johan@kernel.org>
    USB: serial: mos7840: fix another NULL-deref at open

Javier Martinez Canillas <javier@osg.samsung.com>
    tty: serial: msm: Fix module autoload

Maxime Jayat <maxime.jayat@mobile-devices.fr>
    net: socket: fix recvmmsg not returning error from sock_error

Paolo Abeni <pabeni@redhat.com>
    ip: fix IP_CHECKSUM handling

David S. Miller <davem@davemloft.net>
    irda: Fix lockdep annotations in hashbin_delete().

Andrey Konovalov <andreyknvl@google.com>
    dccp: fix freeing skb too early for IPV6_RECVPKTINFO

Anoob Soman <anoob.soman@citrix.com>
    packet: Do not call fanout_release from atomic contexts

Eric Dumazet <edumazet@google.com>
    packet: fix races in fanout_add()

Eric Dumazet <edumazet@google.com>
    net/llc: avoid BUG_ON() in skb_orphan()

Omar Sandoval <osandov@fb.com>
    blk-mq: really fix plug list flushing for nomerge queues

Colin Ian King <colin.king@canonical.com>
    rtc: interface: ignore expired timers when enqueuing new timers

Larry Finger <Larry.Finger@lwfinger.net>
    rtlwifi: rtl_usb: Fix missing entry in USB driver's private data


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

Diffstat:

 Documentation/kernel-parameters.txt        |  4 ++
 Makefile                                   |  4 +-
 arch/x86/platform/goldfish/goldfish.c      | 14 +++++-
 block/blk-mq.c                             | 17 ++++---
 drivers/net/wireless/realtek/rtlwifi/usb.c | 19 ++++++++
 drivers/platform/goldfish/pdev_bus.c       | 13 +++---
 drivers/rtc/interface.c                    | 16 ++++++-
 drivers/tty/serial/msm_serial.c            |  1 +
 drivers/usb/chipidea/ci_hdrc_imx.c         |  1 -
 drivers/usb/serial/ark3116.c               | 13 ++++--
 drivers/usb/serial/cp210x.c                |  2 +
 drivers/usb/serial/digi_acceleport.c       | 14 +++---
 drivers/usb/serial/ftdi_sio.c              | 31 ++++++++-----
 drivers/usb/serial/mos7840.c               |  4 +-
 drivers/usb/serial/opticon.c               |  2 +-
 drivers/usb/serial/spcp8x5.c               |  8 +++-
 mm/backing-dev.c                           |  9 +++-
 net/dccp/input.c                           |  3 +-
 net/ipv4/ip_sockglue.c                     |  8 ++--
 net/irda/irqueue.c                         | 34 +++++++-------
 net/llc/llc_conn.c                         |  3 ++
 net/llc/llc_sap.c                          |  3 ++
 net/packet/af_packet.c                     | 72 +++++++++++++++++++-----------
 net/socket.c                               |  4 +-
 24 files changed, 204 insertions(+), 95 deletions(-)

[PATCH 4.4 01/25] rtlwifi: rtl_usb: Fix missing entry in USB drivers private data

[Greg Kroah-Hartman]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>

commit 60f59ce0278557f7896d5158ae6d12a4855a72cc upstream.

These drivers need to be able to reference "struct ieee80211_hw" from
the driver's private data, and vice versa. The USB driver failed to
store the address of ieee80211_hw in the private data. Although this
bug has been present for a long time, it was not exposed until
commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").

Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/realtek/rtlwifi/usb.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1073,6 +1073,7 @@ int rtl_usb_probe(struct usb_interface *
 		return -ENOMEM;
 	}
 	rtlpriv = hw->priv;
+	rtlpriv->hw = hw;
 	rtlpriv->usb_data = kzalloc(RTL_USB_MAX_RX_COUNT * sizeof(u32),
 				    GFP_KERNEL);
 	if (!rtlpriv->usb_data)

[PATCH 4.4 02/25] rtc: interface: ignore expired timers when enqueuing new timers

[Greg Kroah-Hartman]

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

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

From: Colin Ian King <colin.king@canonical.com>

commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream.

This patch fixes a RTC wakealarm issue, namely, the event fires during
hibernate and is not cleared from the list, causing hwclock to block.

The current enqueuing does not trigger an alarm if any expired timers
already exist on the timerqueue. This can occur when a RTC wake alarm
is used to wake a machine out of hibernate and the resumed state has
old expired timers that have not been removed from the timer queue.
This fix skips over any expired timers and triggers an alarm if there
are no pending timers on the timerqueue. Note that the skipped expired
timer will get reaped later on, so there is no need to clean it up
immediately.

The issue can be reproduced by putting a machine into hibernate and
waking it with the RTC wakealarm.  Running the example RTC test program
from tools/testing/selftests/timers/rtctest.c after the hibernate will
block indefinitely.  With the fix, it no longer blocks after the
hibernate resume.

BugLink: http://bugs.launchpad.net/bugs/1333569

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/rtc/interface.c |   16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -748,9 +748,23 @@ EXPORT_SYMBOL_GPL(rtc_irq_set_freq);
  */
 static int rtc_timer_enqueue(struct rtc_device *rtc, struct rtc_timer *timer)
 {
+	struct timerqueue_node *next = timerqueue_getnext(&rtc->timerqueue);
+	struct rtc_time tm;
+	ktime_t now;
+
 	timer->enabled = 1;
+	__rtc_read_time(rtc, &tm);
+	now = rtc_tm_to_ktime(tm);
+
+	/* Skip over expired timers */
+	while (next) {
+		if (next->expires.tv64 >= now.tv64)
+			break;
+		next = timerqueue_iterate_next(next);
+	}
+
 	timerqueue_add(&rtc->timerqueue, &timer->node);
-	if (&timer->node == timerqueue_getnext(&rtc->timerqueue)) {
+	if (!next) {
 		struct rtc_wkalrm alarm;
 		int err;
 		alarm.time = rtc_ktime_to_tm(timer->node.expires);

[PATCH 4.4 03/25] blk-mq: really fix plug list flushing for nomerge queues

[Greg Kroah-Hartman]

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

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

From: Omar Sandoval <osandov@fb.com>

commit 87c279e613f848c691111b29d49de8df3f4f56da upstream.

Commit 0809e3ac6231 ("block: fix plug list flushing for nomerge queues")
updated blk_mq_make_request() to set request_count even when
blk_queue_nomerges() returns true. However, blk_mq_make_request() only
does limited plugging and doesn't use request_count;
blk_sq_make_request() is the one that should have been fixed. Do that
and get rid of the unnecessary work in the mq version.

Fixes: 0809e3ac6231 ("block: fix plug list flushing for nomerge queues")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/blk-mq.c |   17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1259,12 +1259,9 @@ static blk_qc_t blk_mq_make_request(stru
 
 	blk_queue_split(q, &bio, q->bio_split);
 
-	if (!is_flush_fua && !blk_queue_nomerges(q)) {
-		if (blk_attempt_plug_merge(q, bio, &request_count,
-					   &same_queue_rq))
-			return BLK_QC_T_NONE;
-	} else
-		request_count = blk_plug_queued_count(q);
+	if (!is_flush_fua && !blk_queue_nomerges(q) &&
+	    blk_attempt_plug_merge(q, bio, &request_count, &same_queue_rq))
+		return BLK_QC_T_NONE;
 
 	rq = blk_mq_map_request(q, bio, &data);
 	if (unlikely(!rq))
@@ -1355,9 +1352,11 @@ static blk_qc_t blk_sq_make_request(stru
 
 	blk_queue_split(q, &bio, q->bio_split);
 
-	if (!is_flush_fua && !blk_queue_nomerges(q) &&
-	    blk_attempt_plug_merge(q, bio, &request_count, NULL))
-		return BLK_QC_T_NONE;
+	if (!is_flush_fua && !blk_queue_nomerges(q)) {
+		if (blk_attempt_plug_merge(q, bio, &request_count, NULL))
+			return BLK_QC_T_NONE;
+	} else
+		request_count = blk_plug_queued_count(q);
 
 	rq = blk_mq_map_request(q, bio, &data);
 	if (unlikely(!rq))

[PATCH 4.4 04/25] net/llc: avoid BUG_ON() in skb_orphan()

[Greg Kroah-Hartman]

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

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

From: Eric Dumazet <edumazet@google.com>


[ Upstream commit 8b74d439e1697110c5e5c600643e823eb1dd0762 ]

It seems nobody used LLC since linux-3.12.

Fortunately fuzzers like syzkaller still know how to run this code,
otherwise it would be no fun.

Setting skb->sk without skb->destructor leads to all kinds of
bugs, we now prefer to be very strict about it.

Ideally here we would use skb_set_owner() but this helper does not exist yet,
only CAN seems to have a private helper for that.

Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/llc/llc_conn.c |    3 +++
 net/llc/llc_sap.c  |    3 +++
 2 files changed, 6 insertions(+)

--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -821,7 +821,10 @@ void llc_conn_handler(struct llc_sap *sa
 		 * another trick required to cope with how the PROCOM state
 		 * machine works. -acme
 		 */
+		skb_orphan(skb);
+		sock_hold(sk);
 		skb->sk = sk;
+		skb->destructor = sock_efree;
 	}
 	if (!sock_owned_by_user(sk))
 		llc_conn_rcv(sk, skb);
--- a/net/llc/llc_sap.c
+++ b/net/llc/llc_sap.c
@@ -290,7 +290,10 @@ static void llc_sap_rcv(struct llc_sap *
 
 	ev->type   = LLC_SAP_EV_TYPE_PDU;
 	ev->reason = 0;
+	skb_orphan(skb);
+	sock_hold(sk);
 	skb->sk = sk;
+	skb->destructor = sock_efree;
 	llc_sap_state_process(sap, skb);
 }
 

[PATCH 4.4 05/25] packet: fix races in fanout_add()

[Greg Kroah-Hartman]

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

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

From: Eric Dumazet <edumazet@google.com>


[ Upstream commit d199fab63c11998a602205f7ee7ff7c05c97164b ]

Multiple threads can call fanout_add() at the same time.

We need to grab fanout_mutex earlier to avoid races that could
lead to one thread freeing po->rollover that was set by another thread.

Do the same in fanout_release(), for peace of mind, and to help us
finding lockdep issues earlier.

Fixes: dc99f600698d ("packet: Add fanout support.")
Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/packet/af_packet.c |   53 ++++++++++++++++++++++++++-----------------------
 1 file changed, 29 insertions(+), 24 deletions(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1623,6 +1623,7 @@ static void fanout_release_data(struct p
 
 static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
 {
+	struct packet_rollover *rollover = NULL;
 	struct packet_sock *po = pkt_sk(sk);
 	struct packet_fanout *f, *match;
 	u8 type = type_flags & 0xff;
@@ -1645,23 +1646,28 @@ static int fanout_add(struct sock *sk, u
 		return -EINVAL;
 	}
 
+	mutex_lock(&fanout_mutex);
+
+	err = -EINVAL;
 	if (!po->running)
-		return -EINVAL;
+		goto out;
 
+	err = -EALREADY;
 	if (po->fanout)
-		return -EALREADY;
+		goto out;
 
 	if (type == PACKET_FANOUT_ROLLOVER ||
 	    (type_flags & PACKET_FANOUT_FLAG_ROLLOVER)) {
-		po->rollover = kzalloc(sizeof(*po->rollover), GFP_KERNEL);
-		if (!po->rollover)
-			return -ENOMEM;
-		atomic_long_set(&po->rollover->num, 0);
-		atomic_long_set(&po->rollover->num_huge, 0);
-		atomic_long_set(&po->rollover->num_failed, 0);
+		err = -ENOMEM;
+		rollover = kzalloc(sizeof(*rollover), GFP_KERNEL);
+		if (!rollover)
+			goto out;
+		atomic_long_set(&rollover->num, 0);
+		atomic_long_set(&rollover->num_huge, 0);
+		atomic_long_set(&rollover->num_failed, 0);
+		po->rollover = rollover;
 	}
 
-	mutex_lock(&fanout_mutex);
 	match = NULL;
 	list_for_each_entry(f, &fanout_list, list) {
 		if (f->id == id &&
@@ -1708,11 +1714,11 @@ static int fanout_add(struct sock *sk, u
 		}
 	}
 out:
-	mutex_unlock(&fanout_mutex);
-	if (err) {
-		kfree(po->rollover);
+	if (err && rollover) {
+		kfree(rollover);
 		po->rollover = NULL;
 	}
+	mutex_unlock(&fanout_mutex);
 	return err;
 }
 
@@ -1721,23 +1727,22 @@ static void fanout_release(struct sock *
 	struct packet_sock *po = pkt_sk(sk);
 	struct packet_fanout *f;
 
+	mutex_lock(&fanout_mutex);
 	f = po->fanout;
-	if (!f)
-		return;
+	if (f) {
+		po->fanout = NULL;
 
-	mutex_lock(&fanout_mutex);
-	po->fanout = NULL;
+		if (atomic_dec_and_test(&f->sk_ref)) {
+			list_del(&f->list);
+			dev_remove_pack(&f->prot_hook);
+			fanout_release_data(f);
+			kfree(f);
+		}
 
-	if (atomic_dec_and_test(&f->sk_ref)) {
-		list_del(&f->list);
-		dev_remove_pack(&f->prot_hook);
-		fanout_release_data(f);
-		kfree(f);
+		if (po->rollover)
+			kfree_rcu(po->rollover, rcu);
 	}
 	mutex_unlock(&fanout_mutex);
-
-	if (po->rollover)
-		kfree_rcu(po->rollover, rcu);
 }
 
 static bool packet_extra_vlan_len_allowed(const struct net_device *dev,

[PATCH 4.4 06/25] packet: Do not call fanout_release from atomic contexts

[Greg Kroah-Hartman]

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

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

From: Anoob Soman <anoob.soman@citrix.com>


[ Upstream commit 2bd624b4611ffee36422782d16e1c944d1351e98 ]

Commit 6664498280cf ("packet: call fanout_release, while UNREGISTERING a
netdev"), unfortunately, introduced the following issues.

1. calling mutex_lock(&fanout_mutex) (fanout_release()) from inside
rcu_read-side critical section. rcu_read_lock disables preemption, most often,
which prohibits calling sleeping functions.

[  ] include/linux/rcupdate.h:560 Illegal context switch in RCU read-side critical section!
[  ]
[  ] rcu_scheduler_active = 1, debug_locks = 0
[  ] 4 locks held by ovs-vswitchd/1969:
[  ]  #0:  (cb_lock){++++++}, at: [<ffffffff8158a6c9>] genl_rcv+0x19/0x40
[  ]  #1:  (ovs_mutex){+.+.+.}, at: [<ffffffffa04878ca>] ovs_vport_cmd_del+0x4a/0x100 [openvswitch]
[  ]  #2:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81564157>] rtnl_lock+0x17/0x20
[  ]  #3:  (rcu_read_lock){......}, at: [<ffffffff81614165>] packet_notifier+0x5/0x3f0
[  ]
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff810c9077>] lockdep_rcu_suspicious+0x107/0x110
[  ]  [<ffffffff810a2da7>] ___might_sleep+0x57/0x210
[  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
[  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
[  ]  [<ffffffff810de93f>] ? vprintk_default+0x1f/0x30
[  ]  [<ffffffff81186e88>] ? printk+0x4d/0x4f
[  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

2. calling mutex_lock(&fanout_mutex) inside spin_lock(&po->bind_lock).
"sleeping function called from invalid context"

[  ] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
[  ] in_atomic(): 1, irqs_disabled(): 0, pid: 1969, name: ovs-vswitchd
[  ] INFO: lockdep is turned off.
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff810a2f52>] ___might_sleep+0x202/0x210
[  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
[  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
[  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

3. calling dev_remove_pack(&fanout->prot_hook), from inside
spin_lock(&po->bind_lock) or rcu_read-side critical-section. dev_remove_pack()
-> synchronize_net(), which might sleep.

[  ] BUG: scheduling while atomic: ovs-vswitchd/1969/0x00000002
[  ] INFO: lockdep is turned off.
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff81186274>] __schedule_bug+0x64/0x73
[  ]  [<ffffffff8162b8cb>] __schedule+0x6b/0xd10
[  ]  [<ffffffff8162c5db>] schedule+0x6b/0x80
[  ]  [<ffffffff81630b1d>] schedule_timeout+0x38d/0x410
[  ]  [<ffffffff810ea3fd>] synchronize_sched_expedited+0x53d/0x810
[  ]  [<ffffffff810ea6de>] synchronize_rcu_expedited+0xe/0x10
[  ]  [<ffffffff8154eab5>] synchronize_net+0x35/0x50
[  ]  [<ffffffff8154eae3>] dev_remove_pack+0x13/0x20
[  ]  [<ffffffff8161077e>] fanout_release+0xbe/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

4. fanout_release() races with calls from different CPU.

To fix the above problems, remove the call to fanout_release() under
rcu_read_lock(). Instead, call __dev_remove_pack(&fanout->prot_hook) and
netdev_run_todo will be happy that &dev->ptype_specific list is empty. In order
to achieve this, I moved dev_{add,remove}_pack() out of fanout_{add,release} to
__fanout_{link,unlink}. So, call to {,__}unregister_prot_hook() will make sure
fanout->prot_hook is removed as well.

Fixes: 6664498280cf ("packet: call fanout_release, while UNREGISTERING a netdev")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Anoob Soman <anoob.soman@citrix.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/packet/af_packet.c |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1497,6 +1497,8 @@ static void __fanout_link(struct sock *s
 	f->arr[f->num_members] = sk;
 	smp_wmb();
 	f->num_members++;
+	if (f->num_members == 1)
+		dev_add_pack(&f->prot_hook);
 	spin_unlock(&f->lock);
 }
 
@@ -1513,6 +1515,8 @@ static void __fanout_unlink(struct sock
 	BUG_ON(i >= f->num_members);
 	f->arr[i] = f->arr[f->num_members - 1];
 	f->num_members--;
+	if (f->num_members == 0)
+		__dev_remove_pack(&f->prot_hook);
 	spin_unlock(&f->lock);
 }
 
@@ -1697,7 +1701,6 @@ static int fanout_add(struct sock *sk, u
 		match->prot_hook.func = packet_rcv_fanout;
 		match->prot_hook.af_packet_priv = match;
 		match->prot_hook.id_match = match_fanout_group;
-		dev_add_pack(&match->prot_hook);
 		list_add(&match->list, &fanout_list);
 	}
 	err = -EINVAL;
@@ -1722,7 +1725,12 @@ out:
 	return err;
 }
 
-static void fanout_release(struct sock *sk)
+/* If pkt_sk(sk)->fanout->sk_ref is zero, this function removes
+ * pkt_sk(sk)->fanout from fanout_list and returns pkt_sk(sk)->fanout.
+ * It is the responsibility of the caller to call fanout_release_data() and
+ * free the returned packet_fanout (after synchronize_net())
+ */
+static struct packet_fanout *fanout_release(struct sock *sk)
 {
 	struct packet_sock *po = pkt_sk(sk);
 	struct packet_fanout *f;
@@ -1732,17 +1740,17 @@ static void fanout_release(struct sock *
 	if (f) {
 		po->fanout = NULL;
 
-		if (atomic_dec_and_test(&f->sk_ref)) {
+		if (atomic_dec_and_test(&f->sk_ref))
 			list_del(&f->list);
-			dev_remove_pack(&f->prot_hook);
-			fanout_release_data(f);
-			kfree(f);
-		}
+		else
+			f = NULL;
 
 		if (po->rollover)
 			kfree_rcu(po->rollover, rcu);
 	}
 	mutex_unlock(&fanout_mutex);
+
+	return f;
 }
 
 static bool packet_extra_vlan_len_allowed(const struct net_device *dev,
@@ -2851,6 +2859,7 @@ static int packet_release(struct socket
 {
 	struct sock *sk = sock->sk;
 	struct packet_sock *po;
+	struct packet_fanout *f;
 	struct net *net;
 	union tpacket_req_u req_u;
 
@@ -2890,9 +2899,14 @@ static int packet_release(struct socket
 		packet_set_ring(sk, &req_u, 1, 1);
 	}
 
-	fanout_release(sk);
+	f = fanout_release(sk);
 
 	synchronize_net();
+
+	if (f) {
+		fanout_release_data(f);
+		kfree(f);
+	}
 	/*
 	 *	Now the socket is dead. No more input will appear.
 	 */
@@ -3866,7 +3880,6 @@ static int packet_notifier(struct notifi
 				}
 				if (msg == NETDEV_UNREGISTER) {
 					packet_cached_dev_reset(po);
-					fanout_release(sk);
 					po->ifindex = -1;
 					if (po->prot_hook.dev)
 						dev_put(po->prot_hook.dev);

[PATCH 4.4 07/25] dccp: fix freeing skb too early for IPV6_RECVPKTINFO

[Greg Kroah-Hartman]

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

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

From: Andrey Konovalov <andreyknvl@google.com>


[ Upstream commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 ]

In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
is forcibly freed via __kfree_skb in dccp_rcv_state_process if
dccp_v6_conn_request successfully returns.

However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
is saved to ireq->pktopts and the ref count for skb is incremented in
dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
in dccp_rcv_state_process.

Fix by calling consume_skb instead of doing goto discard and therefore
calling __kfree_skb.

Similar fixes for TCP:

fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
simply consumed

Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/dccp/input.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -606,7 +606,8 @@ int dccp_rcv_state_process(struct sock *
 			if (inet_csk(sk)->icsk_af_ops->conn_request(sk,
 								    skb) < 0)
 				return 1;
-			goto discard;
+			consume_skb(skb);
+			return 0;
 		}
 		if (dh->dccph_type == DCCP_PKT_RESET)
 			goto discard;

[PATCH 4.4 08/25] irda: Fix lockdep annotations in hashbin_delete().

[Greg Kroah-Hartman]

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

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

From: "David S. Miller" <davem@davemloft.net>


[ Upstream commit 4c03b862b12f980456f9de92db6d508a4999b788 ]

A nested lock depth was added to the hasbin_delete() code but it
doesn't actually work some well and results in tons of lockdep splats.

Fix the code instead to properly drop the lock around the operation
and just keep peeking the head of the hashbin queue.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/irda/irqueue.c |   34 ++++++++++++++++------------------
 1 file changed, 16 insertions(+), 18 deletions(-)

--- a/net/irda/irqueue.c
+++ b/net/irda/irqueue.c
@@ -383,9 +383,6 @@ EXPORT_SYMBOL(hashbin_new);
  *    for deallocating this structure if it's complex. If not the user can
  *    just supply kfree, which should take care of the job.
  */
-#ifdef CONFIG_LOCKDEP
-static int hashbin_lock_depth = 0;
-#endif
 int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
 {
 	irda_queue_t* queue;
@@ -396,22 +393,27 @@ int hashbin_delete( hashbin_t* hashbin,
 	IRDA_ASSERT(hashbin->magic == HB_MAGIC, return -1;);
 
 	/* Synchronize */
-	if ( hashbin->hb_type & HB_LOCK ) {
-		spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags,
-					 hashbin_lock_depth++);
-	}
+	if (hashbin->hb_type & HB_LOCK)
+		spin_lock_irqsave(&hashbin->hb_spinlock, flags);
 
 	/*
 	 *  Free the entries in the hashbin, TODO: use hashbin_clear when
 	 *  it has been shown to work
 	 */
 	for (i = 0; i < HASHBIN_SIZE; i ++ ) {
-		queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);
-		while (queue ) {
-			if (free_func)
-				(*free_func)(queue);
-			queue = dequeue_first(
-				(irda_queue_t**) &hashbin->hb_queue[i]);
+		while (1) {
+			queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);
+
+			if (!queue)
+				break;
+
+			if (free_func) {
+				if (hashbin->hb_type & HB_LOCK)
+					spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
+				free_func(queue);
+				if (hashbin->hb_type & HB_LOCK)
+					spin_lock_irqsave(&hashbin->hb_spinlock, flags);
+			}
 		}
 	}
 
@@ -420,12 +422,8 @@ int hashbin_delete( hashbin_t* hashbin,
 	hashbin->magic = ~HB_MAGIC;
 
 	/* Release lock */
-	if ( hashbin->hb_type & HB_LOCK) {
+	if (hashbin->hb_type & HB_LOCK)
 		spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
-#ifdef CONFIG_LOCKDEP
-		hashbin_lock_depth--;
-#endif
-	}
 
 	/*
 	 *  Free the hashbin structure

[PATCH 4.4 09/25] ip: fix IP_CHECKSUM handling

[Greg Kroah-Hartman]

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

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

From: Paolo Abeni <pabeni@redhat.com>


[ Upstream commit ca4ef4574f1ee5252e2cd365f8f5d5bafd048f32 ]

The skbs processed by ip_cmsg_recv() are not guaranteed to
be linear e.g. when sending UDP packets over loopback with
MSGMORE.
Using csum_partial() on [potentially] the whole skb len
is dangerous; instead be on the safe side and use skb_checksum().

Thanks to syzkaller team to detect the issue and provide the
reproducer.

v1 -> v2:
 - move the variable declaration in a tighter scope

Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/ip_sockglue.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -105,10 +105,10 @@ static void ip_cmsg_recv_checksum(struct
 	if (skb->ip_summed != CHECKSUM_COMPLETE)
 		return;
 
-	if (offset != 0)
-		csum = csum_sub(csum,
-				csum_partial(skb->data + tlen,
-					     offset, 0));
+	if (offset != 0) {
+		int tend_off = skb_transport_offset(skb) + tlen;
+		csum = csum_sub(csum, skb_checksum(skb, tend_off, offset, 0));
+	}
 
 	put_cmsg(msg, SOL_IP, IP_CHECKSUM, sizeof(__wsum), &csum);
 }

[PATCH 4.4 10/25] net: socket: fix recvmmsg not returning error from sock_error

[Greg Kroah-Hartman]

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

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

From: Maxime Jayat <maxime.jayat@mobile-devices.fr>


[ Upstream commit e623a9e9dec29ae811d11f83d0074ba254aba374 ]

Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"),
changed the exit path of recvmmsg to always return the datagrams
variable and modified the error paths to set the variable to the error
code returned by recvmsg if necessary.

However in the case sock_error returned an error, the error code was
then ignored, and recvmmsg returned 0.

Change the error path of recvmmsg to correctly return the error code
of sock_error.

The bug was triggered by using recvmmsg on a CAN interface which was
not up. Linux 4.6 and later return 0 in this case while earlier
releases returned -ENETDOWN.

Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path")
Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/socket.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/net/socket.c
+++ b/net/socket.c
@@ -2185,8 +2185,10 @@ int __sys_recvmmsg(int fd, struct mmsghd
 		return err;
 
 	err = sock_error(sock->sk);
-	if (err)
+	if (err) {
+		datagrams = err;
 		goto out_put;
+	}
 
 	entry = mmsg;
 	compat_entry = (struct compat_mmsghdr __user *)mmsg;

[PATCH 4.4 11/25] tty: serial: msm: Fix module autoload

[Greg Kroah-Hartman]

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

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

From: Javier Martinez Canillas <javier@osg.samsung.com>

commit abe81f3b8ed2996e1712d26d38ff6b73f582c616 upstream.

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
$

After this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
alias:          of:N*T*Cqcom,msm-uartdmC*
alias:          of:N*T*Cqcom,msm-uartdm
alias:          of:N*T*Cqcom,msm-uartC*
alias:          of:N*T*Cqcom,msm-uart

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/msm_serial.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -1615,6 +1615,7 @@ static const struct of_device_id msm_mat
 	{ .compatible = "qcom,msm-uartdm" },
 	{}
 };
+MODULE_DEVICE_TABLE(of, msm_match_table);
 
 static struct platform_driver msm_platform_driver = {
 	.remove = msm_serial_remove,

[PATCH 4.4 12/25] USB: serial: mos7840: fix another NULL-deref at open

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 5182c2cf2a9bfb7f066ef0bdd2bb6330b94dd74e upstream.

Fix another NULL-pointer dereference at open should a malicious device
lack an interrupt-in endpoint.

Note that the driver has a broken check for an interrupt-in endpoint
which means that an interrupt URB has never even been submitted.

Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/mos7840.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -1024,6 +1024,7 @@ static int mos7840_open(struct tty_struc
 	 * (can't set it up in mos7840_startup as the structures *
 	 * were not set up at that time.)                        */
 	if (port0->open_ports == 1) {
+		/* FIXME: Buffer never NULL, so URB is not submitted. */
 		if (serial->port[0]->interrupt_in_buffer == NULL) {
 			/* set up interrupt urb */
 			usb_fill_int_urb(serial->port[0]->interrupt_in_urb,
@@ -2119,7 +2120,8 @@ static int mos7840_calc_num_ports(struct
 static int mos7840_attach(struct usb_serial *serial)
 {
 	if (serial->num_bulk_in < serial->num_ports ||
-			serial->num_bulk_out < serial->num_ports) {
+			serial->num_bulk_out < serial->num_ports ||
+			serial->num_interrupt_in < 1) {
 		dev_err(&serial->interface->dev, "missing endpoints\n");
 		return -ENODEV;
 	}

[PATCH 4.4 13/25] USB: serial: cp210x: add new IDs for GE Bx50v3 boards

[Greg Kroah-Hartman]

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

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

From: Ken Lin <yungching0725@gmail.com>

commit 9a593656def0dc2f6c227851e8e602077267a5f1 upstream.

Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design
change.

Signed-off-by: Ken Lin <yungching0725@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/cp210x.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -171,6 +171,8 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
 	{ USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
 	{ USB_DEVICE(0x1901, 0x0194) },	/* GE Healthcare Remote Alarm Box */
+	{ USB_DEVICE(0x1901, 0x0195) },	/* GE B850/B650/B450 CP2104 DP UART interface */
+	{ USB_DEVICE(0x1901, 0x0196) },	/* GE B850 CP2105 DP UART interface */
 	{ USB_DEVICE(0x19CF, 0x3000) }, /* Parrot NMEA GPS Flight Recorder */
 	{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
 	{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */

[PATCH 4.4 14/25] USB: serial: ftdi_sio: fix modem-status error handling

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 427c3a95e3e29e65f59d99aaf320d7506f3eed57 upstream.

Make sure to detect short responses when fetching the modem status in
order to avoid parsing uninitialised buffer data and having bits of it
leak to user space.

Note that we still allow for short 1-byte responses.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/ftdi_sio.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2433,8 +2433,12 @@ static int ftdi_get_modem_status(struct
 			FTDI_SIO_GET_MODEM_STATUS_REQUEST_TYPE,
 			0, priv->interface,
 			buf, len, WDR_TIMEOUT);
-	if (ret < 0) {
+
+	/* NOTE: We allow short responses and handle that below. */
+	if (ret < 1) {
 		dev_err(&port->dev, "failed to get modem status: %d\n", ret);
+		if (ret >= 0)
+			ret = -EIO;
 		ret = usb_translate_errors(ret);
 		goto out;
 	}

[PATCH 4.4 15/25] USB: serial: ftdi_sio: fix extreme low-latency setting

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit c6dce2626606ef16434802989466636bc28c1419 upstream.

Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") the FTDI driver has been using a receive latency-timer value of
1 ms instead of the device default of 16 ms.

The latency timer is used to periodically empty a non-full receive
buffer, but a status header is always sent when the timer expires
including when the buffer is empty. This means that a two-byte bulk
message is received every millisecond also for an otherwise idle port as
long as it is open.

Let's restore the pre-2009 behaviour which reduces the rate of the
status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to
62.5 Hz) by not setting ASYNC_LOW_LATENCY by default.

Anyone willing to pay the price for the minimum-latency behaviour should
set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).

Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
to set a minimal latency timer.

Reported-by: Antoine Aubert <a.aubert@overkiz.com>
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/ftdi_sio.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1807,8 +1807,6 @@ static int ftdi_sio_port_probe(struct us
 
 	mutex_init(&priv->cfg_lock);
 
-	priv->flags = ASYNC_LOW_LATENCY;
-
 	if (quirk && quirk->port_probe)
 		quirk->port_probe(priv);
 

[PATCH 4.4 16/25] USB: serial: ftdi_sio: fix line-status over-reporting

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit a6bb1e17a39818b01b55d8e6238b4b5f06d55038 upstream.

FTDI devices use a receive latency timer to periodically empty the
receive buffer and report modem and line status (also when the buffer is
empty).

When a break or error condition is detected the corresponding status
flags will be set on a packet with nonzero data payload and the flags
are not updated until the break is over or further characters are
received.

In order to avoid over-reporting break and error conditions, these flags
must therefore only be processed for packets with payload.

This specifically fixes the case where after an overrun, the error
condition is continuously reported and NULL-characters inserted until
further data is received.

Reported-by: Michael Walle <michael@walle.cc>
Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on
break")
Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/ftdi_sio.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2070,6 +2070,20 @@ static int ftdi_process_packet(struct us
 		priv->prev_status = status;
 	}
 
+	/* save if the transmitter is empty or not */
+	if (packet[1] & FTDI_RS_TEMT)
+		priv->transmit_empty = 1;
+	else
+		priv->transmit_empty = 0;
+
+	len -= 2;
+	if (!len)
+		return 0;	/* status only */
+
+	/*
+	 * Break and error status must only be processed for packets with
+	 * data payload to avoid over-reporting.
+	 */
 	flag = TTY_NORMAL;
 	if (packet[1] & FTDI_RS_ERR_MASK) {
 		/* Break takes precedence over parity, which takes precedence
@@ -2092,15 +2106,6 @@ static int ftdi_process_packet(struct us
 		}
 	}
 
-	/* save if the transmitter is empty or not */
-	if (packet[1] & FTDI_RS_TEMT)
-		priv->transmit_empty = 1;
-	else
-		priv->transmit_empty = 0;
-
-	len -= 2;
-	if (!len)
-		return 0;	/* status only */
 	port->icount.rx += len;
 	ch = packet + 2;
 

[PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 2d380889215fe20b8523345649dee0579821800c upstream.

Make sure to check for short transfers to avoid underflow in a loop
condition when parsing the receive buffer.

Also fix an off-by-one error in the incomplete sanity check which could
lead to invalid data being parsed.

Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/digi_acceleport.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -1483,16 +1483,20 @@ static int digi_read_oob_callback(struct
 	struct usb_serial *serial = port->serial;
 	struct tty_struct *tty;
 	struct digi_port *priv = usb_get_serial_port_data(port);
+	unsigned char *buf = urb->transfer_buffer;
 	int opcode, line, status, val;
 	int i;
 	unsigned int rts;
 
+	if (urb->actual_length < 4)
+		return -1;
+
 	/* handle each oob command */
-	for (i = 0; i < urb->actual_length - 3;) {
-		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
-		line = ((unsigned char *)urb->transfer_buffer)[i++];
-		status = ((unsigned char *)urb->transfer_buffer)[i++];
-		val = ((unsigned char *)urb->transfer_buffer)[i++];
+	for (i = 0; i < urb->actual_length - 4; i += 4) {
+		opcode = buf[i];
+		line = buf[i + 1];
+		status = buf[i + 2];
+		val = buf[i + 3];
 
 		dev_dbg(&port->dev, "digi_read_oob_callback: opcode=%d, line=%d, status=%d, val=%d\n",
 			opcode, line, status, val);

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Johan Hovold <johan@kernel.org>
> 
> commit 2d380889215fe20b8523345649dee0579821800c upstream.
> 
> Make sure to check for short transfers to avoid underflow in a loop
> condition when parsing the receive buffer.
> 
> Also fix an off-by-one error in the incomplete sanity check which could
> lead to invalid data being parsed.

This appears to *introduce* an off-by-one.  Which is not as serious as
the underflow, but is still a regression.

Suppose we have urb->actual_length == 4:

[...]
> -	for (i = 0; i < urb->actual_length - 3;) {

i < 1 is true, so we would run the loop once.

> -		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> -		line = ((unsigned char *)urb->transfer_buffer)[i++];
> -		status = ((unsigned char *)urb->transfer_buffer)[i++];
> -		val = ((unsigned char *)urb->transfer_buffer)[i++];
> +	for (i = 0; i < urb->actual_length - 4; i += 4) {

i < 0 is false, so we now skip the loop.

> +		opcode = buf[i];
> +		line = buf[i + 1];
> +		status = buf[i + 2];
> +		val = buf[i + 3];
[...]

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Johan Hovold]

On Fri, Feb 24, 2017 at 01:38:25PM +0000, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Johan Hovold <johan@kernel.org>
> > 
> > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > 
> > Make sure to check for short transfers to avoid underflow in a loop
> > condition when parsing the receive buffer.
> > 
> > Also fix an off-by-one error in the incomplete sanity check which could
> > lead to invalid data being parsed.
> 
> This appears to *introduce* an off-by-one.  Which is not as serious as
> the underflow, but is still a regression.
> 
> Suppose we have urb->actual_length == 4:
> 
> [...]
> > -	for (i = 0; i < urb->actual_length - 3;) {
> 
> i < 1 is true, so we would run the loop once.
> 
> > -		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > -		line = ((unsigned char *)urb->transfer_buffer)[i++];
> > -		status = ((unsigned char *)urb->transfer_buffer)[i++];
> > -		val = ((unsigned char *)urb->transfer_buffer)[i++];
> > +	for (i = 0; i < urb->actual_length - 4; i += 4) {
> 
> i < 0 is false, so we now skip the loop.

Good catch, thanks! The original loop condition was indeed correct
(modulo the missing underflow check), and I'll post a follow-up fix to
address this.

> > +		opcode = buf[i];
> > +		line = buf[i + 1];
> > +		status = buf[i + 2];
> > +		val = buf[i + 3];

You should probably not apply this one until after the follow-up is in
Linus' tree as this patch breaks TIOCMGET.

Thanks,
Johan

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg Kroah-Hartman]

On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> On Fri, Feb 24, 2017 at 01:38:25PM +0000, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Johan Hovold <johan@kernel.org>
> > > 
> > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > 
> > > Make sure to check for short transfers to avoid underflow in a loop
> > > condition when parsing the receive buffer.
> > > 
> > > Also fix an off-by-one error in the incomplete sanity check which could
> > > lead to invalid data being parsed.
> > 
> > This appears to *introduce* an off-by-one.  Which is not as serious as
> > the underflow, but is still a regression.
> > 
> > Suppose we have urb->actual_length == 4:
> > 
> > [...]
> > > -	for (i = 0; i < urb->actual_length - 3;) {
> > 
> > i < 1 is true, so we would run the loop once.
> > 
> > > -		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > > -		line = ((unsigned char *)urb->transfer_buffer)[i++];
> > > -		status = ((unsigned char *)urb->transfer_buffer)[i++];
> > > -		val = ((unsigned char *)urb->transfer_buffer)[i++];
> > > +	for (i = 0; i < urb->actual_length - 4; i += 4) {
> > 
> > i < 0 is false, so we now skip the loop.
> 
> Good catch, thanks! The original loop condition was indeed correct
> (modulo the missing underflow check), and I'll post a follow-up fix to
> address this.
> 
> > > +		opcode = buf[i];
> > > +		line = buf[i + 1];
> > > +		status = buf[i + 2];
> > > +		val = buf[i + 3];
> 
> You should probably not apply this one until after the follow-up is in
> Linus' tree as this patch breaks TIOCMGET.

Ok, I'll drop this one from the stable tree now.  Remind me to pick this
one up when the fixup hits Linus's tree.

thanks,

greg k-h

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Johan Hovold]

On Fri, Feb 24, 2017 at 06:55:02PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> > On Fri, Feb 24, 2017 at 01:38:25PM +0000, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Johan Hovold <johan@kernel.org>
> > > > 
> > > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > > 
> > > > Make sure to check for short transfers to avoid underflow in a loop
> > > > condition when parsing the receive buffer.
> > > > 
> > > > Also fix an off-by-one error in the incomplete sanity check which could
> > > > lead to invalid data being parsed.
> > > 
> > > This appears to *introduce* an off-by-one.  Which is not as serious as
> > > the underflow, but is still a regression.

> > Good catch, thanks! The original loop condition was indeed correct
> > (modulo the missing underflow check), and I'll post a follow-up fix to
> > address this.

> > You should probably not apply this one until after the follow-up is in
> > Linus' tree as this patch breaks TIOCMGET.
> 
> Ok, I'll drop this one from the stable tree now.  Remind me to pick this
> one up when the fixup hits Linus's tree.

Thanks, will do.

Johan

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Johan Hovold]

On Fri, Feb 24, 2017 at 06:55:02PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> > On Fri, Feb 24, 2017 at 01:38:25PM +0000, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Johan Hovold <johan@kernel.org>
> > > > 
> > > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > > 
> > > > Make sure to check for short transfers to avoid underflow in a loop
> > > > condition when parsing the receive buffer.
> > > > 
> > > > Also fix an off-by-one error in the incomplete sanity check which could
> > > > lead to invalid data being parsed.
> > > 
> > > This appears to *introduce* an off-by-one.  Which is not as serious as
> > > the underflow, but is still a regression.
> > > 
> > > Suppose we have urb->actual_length == 4:
> > > 
> > > [...]
> > > > -	for (i = 0; i < urb->actual_length - 3;) {
> > > 
> > > i < 1 is true, so we would run the loop once.
> > > 
> > > > -		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > -		line = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > -		status = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > -		val = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > +	for (i = 0; i < urb->actual_length - 4; i += 4) {
> > > 
> > > i < 0 is false, so we now skip the loop.
> > 
> > Good catch, thanks! The original loop condition was indeed correct
> > (modulo the missing underflow check), and I'll post a follow-up fix to
> > address this.
> > 
> > > > +		opcode = buf[i];
> > > > +		line = buf[i + 1];
> > > > +		status = buf[i + 2];
> > > > +		val = buf[i + 3];
> > 
> > You should probably not apply this one until after the follow-up is in
> > Linus' tree as this patch breaks TIOCMGET.
> 
> Ok, I'll drop this one from the stable tree now.  Remind me to pick this
> one up when the fixup hits Linus's tree.

The follow-up fix is now in Linus's tree so both this one:

	2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check")

and the follow-up:

	2e46565cf622 ("USB: serial: digi_acceleport: fix OOB-event processing")

can now be applied to the stable trees.

Thanks,
Johan

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg Kroah-Hartman]

On Mon, Mar 13, 2017 at 06:14:37PM +0100, Johan Hovold wrote:
> On Fri, Feb 24, 2017 at 06:55:02PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> > > On Fri, Feb 24, 2017 at 01:38:25PM +0000, Ben Hutchings wrote: > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > > > 
> > > > > ------------------
> > > > > 
> > > > > From: Johan Hovold <johan@kernel.org>
> > > > > 
> > > > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > > > 
> > > > > Make sure to check for short transfers to avoid underflow in a loop
> > > > > condition when parsing the receive buffer.
> > > > > 
> > > > > Also fix an off-by-one error in the incomplete sanity check which could
> > > > > lead to invalid data being parsed.
> > > > 
> > > > This appears to *introduce* an off-by-one.  Which is not as serious as
> > > > the underflow, but is still a regression.
> > > > 
> > > > Suppose we have urb->actual_length == 4:
> > > > 
> > > > [...]
> > > > > -	for (i = 0; i < urb->actual_length - 3;) {
> > > > 
> > > > i < 1 is true, so we would run the loop once.
> > > > 
> > > > > -		opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > -		line = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > -		status = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > -		val = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > +	for (i = 0; i < urb->actual_length - 4; i += 4) {
> > > > 
> > > > i < 0 is false, so we now skip the loop.
> > > 
> > > Good catch, thanks! The original loop condition was indeed correct
> > > (modulo the missing underflow check), and I'll post a follow-up fix to
> > > address this.
> > > 
> > > > > +		opcode = buf[i];
> > > > > +		line = buf[i + 1];
> > > > > +		status = buf[i + 2];
> > > > > +		val = buf[i + 3];
> > > 
> > > You should probably not apply this one until after the follow-up is in
> > > Linus' tree as this patch breaks TIOCMGET.
> > 
> > Ok, I'll drop this one from the stable tree now.  Remind me to pick this
> > one up when the fixup hits Linus's tree.
> 
> The follow-up fix is now in Linus's tree so both this one:
> 
> 	2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check")
> 
> and the follow-up:
> 
> 	2e46565cf622 ("USB: serial: digi_acceleport: fix OOB-event processing")
> 
> can now be applied to the stable trees.

Thanks, now queued up.

greg k-h

[PATCH 4.4 18/25] USB: serial: spcp8x5: fix modem-status handling

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 5ed8d41023751bdd3546f2fe4118304357efe8d2 upstream.

Make sure to detect short control transfers and return zero on success
when retrieving the modem status.

This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB:
spcp8x5: add proper modem-status support") has returned TIOCM_LE on
successful retrieval, and avoids leaking bits from the stack on short
transfers.

This also fixes the carrier-detect implementation which since the above
mentioned commit unconditionally has returned true.

Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/spcp8x5.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/usb/serial/spcp8x5.c
+++ b/drivers/usb/serial/spcp8x5.c
@@ -232,11 +232,17 @@ static int spcp8x5_get_msr(struct usb_se
 	ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
 			      GET_UART_STATUS, GET_UART_STATUS_TYPE,
 			      0, GET_UART_STATUS_MSR, buf, 1, 100);
-	if (ret < 0)
+	if (ret < 1) {
 		dev_err(&port->dev, "failed to get modem status: %d\n", ret);
+		if (ret >= 0)
+			ret = -EIO;
+		goto out;
+	}
 
 	dev_dbg(&port->dev, "0xc0:0x22:0:6  %d - 0x02%x\n", ret, *buf);
 	*status = *buf;
+	ret = 0;
+out:
 	kfree(buf);
 
 	return ret;

[PATCH 4.4 19/25] USB: serial: opticon: fix CTS retrieval at open

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 2eee05020a0e7ee7c04422cbacdb07859e45dce6 upstream.

The opticon driver used a control request at open to trigger a CTS
status notification to be sent over the bulk-in pipe. When the driver
was converted to using the generic read implementation, an inverted test
prevented this request from being sent, something which could lead to
TIOCMGET reporting an incorrect CTS state.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/opticon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -142,7 +142,7 @@ static int opticon_open(struct tty_struc
 	usb_clear_halt(port->serial->dev, port->read_urb->pipe);
 
 	res = usb_serial_generic_open(tty, port);
-	if (!res)
+	if (res)
 		return res;
 
 	/* Request CTS line state, sometimes during opening the current

[PATCH 4.4 20/25] USB: serial: ark3116: fix register-accessor error handling

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 upstream.

The current implementation failed to detect short transfers, something
which could lead to bits of the uninitialised heap transfer buffer
leaking to user space.

Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.")
Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/ark3116.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/ark3116.c
+++ b/drivers/usb/serial/ark3116.c
@@ -99,10 +99,17 @@ static int ark3116_read_reg(struct usb_s
 				 usb_rcvctrlpipe(serial->dev, 0),
 				 0xfe, 0xc0, 0, reg,
 				 buf, 1, ARK_TIMEOUT);
-	if (result < 0)
+	if (result < 1) {
+		dev_err(&serial->interface->dev,
+				"failed to read register %u: %d\n",
+				reg, result);
+		if (result >= 0)
+			result = -EIO;
+
 		return result;
-	else
-		return buf[0];
+	}
+
+	return buf[0];
 }
 
 static inline int calc_divisor(int bps)

[PATCH 4.4 21/25] x86/platform/goldfish: Prevent unconditional loading

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb upstream.

The goldfish platform code registers the platform device unconditionally
which causes havoc in several ways if the goldfish_pdev_bus driver is
enabled:

 - Access to the hardcoded physical memory region, which is either not
   available or contains stuff which is completely unrelated.

 - Prevents that the interrupt of the serial port can be requested

 - In case of a spurious interrupt it goes into a infinite loop in the
   interrupt handler of the pdev_bus driver (which needs to be fixed
   seperately).

Add a 'goldfish' command line option to make the registration opt-in when
the platform is compiled in.

I'm seriously grumpy about this engineering trainwreck, which has seven
SOBs from Intel developers for 50 lines of code. And none of them figured
out that this is broken. Impressive fail!

Fixes: ddd70cf93d78 ("goldfish: platform device for x86")
Reported-by: Gabriel C <nix.or.die@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Documentation/kernel-parameters.txt   |    4 ++++
 arch/x86/platform/goldfish/goldfish.c |   14 +++++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1255,6 +1255,10 @@ bytes respectively. Such letter suffixes
 			When zero, profiling data is discarded and associated
 			debugfs files are removed at module unload time.
 
+	goldfish	[X86] Enable the goldfish android emulator platform.
+			Don't use this when you are not running on the
+			android emulator
+
 	gpt		[EFI] Forces disk with valid GPT signature but
 			invalid Protective MBR to be treated as GPT. If the
 			primary GPT is corrupted, it enables the backup/alternate
--- a/arch/x86/platform/goldfish/goldfish.c
+++ b/arch/x86/platform/goldfish/goldfish.c
@@ -42,10 +42,22 @@ static struct resource goldfish_pdev_bus
 	}
 };
 
+static bool goldfish_enable __initdata;
+
+static int __init goldfish_setup(char *str)
+{
+	goldfish_enable = true;
+	return 0;
+}
+__setup("goldfish", goldfish_setup);
+
 static int __init goldfish_init(void)
 {
+	if (!goldfish_enable)
+		return -ENODEV;
+
 	platform_device_register_simple("goldfish_pdev_bus", -1,
-						goldfish_pdev_bus_resources, 2);
+					goldfish_pdev_bus_resources, 2);
 	return 0;
 }
 device_initcall(goldfish_init);

[PATCH 4.4 22/25] goldfish: Sanitize the broken interrupt handler

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream.

This interrupt handler is broken in several ways:

  - It loops forever when the op code is not decodeable

  - It never returns IRQ_HANDLED because the only way to exit the loop
    returns IRQ_NONE unconditionally.

The whole concept of this is broken. Creating devices in an interrupt
handler is beyond any point of sanity.

Make it at least behave halfways sane so accidental users do not have to
deal with a hard to debug lockup.

Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus")
Reported-by: Gabriel C <nix.or.die@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/platform/goldfish/pdev_bus.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/platform/goldfish/pdev_bus.c
+++ b/drivers/platform/goldfish/pdev_bus.c
@@ -157,23 +157,26 @@ static int goldfish_new_pdev(void)
 static irqreturn_t goldfish_pdev_bus_interrupt(int irq, void *dev_id)
 {
 	irqreturn_t ret = IRQ_NONE;
+
 	while (1) {
 		u32 op = readl(pdev_bus_base + PDEV_BUS_OP);
-		switch (op) {
-		case PDEV_BUS_OP_DONE:
-			return IRQ_NONE;
 
+		switch (op) {
 		case PDEV_BUS_OP_REMOVE_DEV:
 			goldfish_pdev_remove();
+			ret = IRQ_HANDLED;
 			break;
 
 		case PDEV_BUS_OP_ADD_DEV:
 			goldfish_new_pdev();
+			ret = IRQ_HANDLED;
 			break;
+
+		case PDEV_BUS_OP_DONE:
+		default:
+			return ret;
 		}
-		ret = IRQ_HANDLED;
 	}
-	return ret;
 }
 
 static int goldfish_pdev_bus_probe(struct platform_device *pdev)

[PATCH 4.4 23/25] block: fix double-free in the failure path of cgwb_bdi_init()

[Greg Kroah-Hartman]

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

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

From: Tejun Heo <tj@kernel.org>

commit 5f478e4ea5c5560b4e40eb136991a09f9389f331 upstream.

When !CONFIG_CGROUP_WRITEBACK, bdi has single bdi_writeback_congested
at bdi->wb_congested.  cgwb_bdi_init() allocates it with kzalloc() and
doesn't do further initialization.  This usually works fine as the
reference count gets bumped to 1 by wb_init() and the put from
wb_exit() releases it.

However, when wb_init() fails, it puts the wb base ref automatically
freeing the wb and the explicit kfree() in cgwb_bdi_init() error path
ends up trying to free the same pointer the second time causing a
double-free.

Fix it by explicitly initilizing the refcnt to 1 and putting the base
ref from cgwb_bdi_destroy().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback")
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/backing-dev.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -757,15 +757,20 @@ static int cgwb_bdi_init(struct backing_
 	if (!bdi->wb_congested)
 		return -ENOMEM;
 
+	atomic_set(&bdi->wb_congested->refcnt, 1);
+
 	err = wb_init(&bdi->wb, bdi, 1, GFP_KERNEL);
 	if (err) {
-		kfree(bdi->wb_congested);
+		wb_congested_put(bdi->wb_congested);
 		return err;
 	}
 	return 0;
 }
 
-static void cgwb_bdi_destroy(struct backing_dev_info *bdi) { }
+static void cgwb_bdi_destroy(struct backing_dev_info *bdi)
+{
+	wb_congested_put(bdi->wb_congested);
+}
 
 #endif	/* CONFIG_CGROUP_WRITEBACK */
 

[PATCH 4.4 24/25] rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down

[Greg Kroah-Hartman]

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

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

From: Michael Schenk <michael.schenk@albis-elcon.com>

commit 575ddce0507789bf9830d089557d2199d2f91865 upstream.

In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.

Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/realtek/rtlwifi/usb.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -834,12 +834,30 @@ static void rtl_usb_stop(struct ieee8021
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
 	struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
 	struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
+	struct urb *urb;
 
 	/* should after adapter start and interrupt enable. */
 	set_hal_stop(rtlhal);
 	cancel_work_sync(&rtlpriv->works.fill_h2c_cmd);
 	/* Enable software */
 	SET_USB_STOP(rtlusb);
+
+	/* free pre-allocated URBs from rtl_usb_start() */
+	usb_kill_anchored_urbs(&rtlusb->rx_submitted);
+
+	tasklet_kill(&rtlusb->rx_work_tasklet);
+	cancel_work_sync(&rtlpriv->works.lps_change_work);
+
+	flush_workqueue(rtlpriv->works.rtl_wq);
+
+	skb_queue_purge(&rtlusb->rx_queue);
+
+	while ((urb = usb_get_from_anchor(&rtlusb->rx_cleanup_urbs))) {
+		usb_free_coherent(urb->dev, urb->transfer_buffer_length,
+				urb->transfer_buffer, urb->transfer_dma);
+		usb_free_urb(urb);
+	}
+
 	rtlpriv->cfg->ops->hw_disable(hw);
 }
 

[PATCH 4.4 25/25] Revert "usb: chipidea: imx: enable CI_HDRC_SET_NON_ZERO_TTHA"

[Greg Kroah-Hartman]

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

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

From: Peter Chen <peter.chen@nxp.com>

commit 1bc7da87c7410c6990c3251589e3854e64c55af2 upstream.

This reverts commit e765bfb73ff7.

In the most of cases, we only use one transaction per frame and the
frame rate may be high, If the platforms want to support multiple
transactions but less frame rate cases like [1] and [2], it can set
"non-zero-ttctrl-ttha" at dts.

[1] http://www.spinics.net/lists/linux-usb/msg123125.html
[2] http://www.spinics.net/lists/linux-usb/msg118679.html

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Cc: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/chipidea/ci_hdrc_imx.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -244,7 +244,6 @@ static int ci_hdrc_imx_probe(struct plat
 	struct ci_hdrc_platform_data pdata = {
 		.name		= dev_name(&pdev->dev),
 		.capoffset	= DEF_CAPOFFSET,
-		.flags		= CI_HDRC_SET_NON_ZERO_TTHA,
 	};
 	int ret;
 	const struct of_device_id *of_id;

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.52 release.
> There are 25 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.
[...]

4.4 is still missing ccf7abb93af0 "tcp: avoid infinite loop in
tcp_splice_read()" although you've applied it to 4.9 (in 4.9.11).  I've
reproduced the bug and fix on 3.2, so I'm confident it's also needed
for 4.4.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Greg Kroah-Hartman]

On Fri, Feb 24, 2017 at 01:55:31PM +0000, Ben Hutchings wrote:
> On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.52 release.
> > There are 25 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.
> [...]
> 
> 4.4 is still missing ccf7abb93af0 "tcp: avoid infinite loop in
> tcp_splice_read()" although you've applied it to 4.9 (in 4.9.11).  I've
> reproduced the bug and fix on 3.2, so I'm confident it's also needed
> for 4.4.

Odd, David didn't include that in his patch mbox he sent to me for
4.4-stable.

David, any objection to me taking the patch for 4.4?

thanks,

greg k-h

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[David Miller]

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 24 Feb 2017 15:43:37 +0100

> On Fri, Feb 24, 2017 at 01:55:31PM +0000, Ben Hutchings wrote:
>> On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
>> > This is the start of the stable review cycle for the 4.4.52 release.
>> > There are 25 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.
>> [...]
>> 
>> 4.4 is still missing ccf7abb93af0 "tcp: avoid infinite loop in
>> tcp_splice_read()" although you've applied it to 4.9 (in 4.9.11).  I've
>> reproduced the bug and fix on 3.2, so I'm confident it's also needed
>> for 4.4.
> 
> Odd, David didn't include that in his patch mbox he sent to me for
> 4.4-stable.
> 
> David, any objection to me taking the patch for 4.4?

No objections.

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Greg Kroah-Hartman]

On Fri, Feb 24, 2017 at 01:55:31PM +0000, Ben Hutchings wrote:
> On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.52 release.
> > There are 25 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.
> [...]
> 
> 4.4 is still missing ccf7abb93af0 "tcp: avoid infinite loop in
> tcp_splice_read()" although you've applied it to 4.9 (in 4.9.11).  I've
> reproduced the bug and fix on 3.2, so I'm confident it's also needed
> for 4.4.

Oops, I just checked, that commit is in 4.4.50, no wonder David didn't
include it in the latest set of patches, it's already been released :)

thanks,

greg k-h

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Fri, 2017-02-24 at 16:41 +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 24, 2017 at 01:55:31PM +0000, Ben Hutchings wrote:
> > On Fri, 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.52 release.
> > > There are 25 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.
> > 
> > [...]
> > 
> > 4.4 is still missing ccf7abb93af0 "tcp: avoid infinite loop in
> > tcp_splice_read()" although you've applied it to 4.9 (in 4.9.11).  I've
> > reproduced the bug and fix on 3.2, so I'm confident it's also needed
> > for 4.4.
> 
> Oops, I just checked, that commit is in 4.4.50, no wonder David didn't
> include it in the latest set of patches, it's already been released :)

Sorry for wasting your time, I must have run the wrong command to check this.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Guenter Roeck]

On 02/24/2017 12:25 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.52 release.
> There are 25 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 Sun Feb 26 08:21:10 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/25] 4.4.52-stable review

[Shuah Khan]

On 02/24/2017 01:25 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.52 release.
> There are 25 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 Sun Feb 26 08:21:10 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.4.52-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.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah