4 years agoLinux 3.18.27 v3.18.27
Sasha Levin [Mon, 15 Feb 2016 20:47:06 +0000 (15:47 -0500)]
Linux 3.18.27

Signed-off-by: Sasha Levin <>
4 years agoxfrm: dst_entries_init() per-net dst_ops
Dan Streetman [Thu, 29 Oct 2015 13:51:16 +0000 (09:51 -0400)]
xfrm: dst_entries_init() per-net dst_ops

[ Upstream commit a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 ]

Remove the dst_entries_init/destroy calls for xfrm4 and xfrm6 dst_ops
templates; their dst_entries counters will never be used.  Move the
xfrm dst_ops initialization from the common xfrm/xfrm_policy.c to
xfrm4/xfrm4_policy.c and xfrm6/xfrm6_policy.c, and call dst_entries_init
and dst_entries_destroy for each net namespace.

The ipv4 and ipv6 xfrms each create dst_ops template, and perform
dst_entries_init on the templates.  The template values are copied to each
net namespace's xfrm.xfrm*_dst_ops.  The problem there is the dst_ops
pcpuc_entries field is a percpu counter and cannot be used correctly by
simply copying it to another object.

The result of this is a very subtle bug; changes to the dst entries
counter from one net namespace may sometimes get applied to a different
net namespace dst entries counter.  This is because of how the percpu
counter works; it has a main count field as well as a pointer to the
percpu variables.  Each net namespace maintains its own main count
variable, but all point to one set of percpu variables.  When any net
namespace happens to change one of the percpu variables to outside its
small batch range, its count is moved to the net namespace's main count
variable.  So with multiple net namespaces operating concurrently, the
dst_ops entries counter can stray from the actual value that it should
be; if counts are consistently moved from one net namespace to another
(which my testing showed is likely), then one net namespace winds up
with a negative dst_ops count while another winds up with a continually
increasing count, eventually reaching its gc_thresh limit, which causes
all new traffic on the net namespace to fail with -ENOBUFS.

Signed-off-by: Dan Streetman <>
Signed-off-by: Dan Streetman <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Sasha Levin <>
4 years agoxen-netfront: update num_queues to real created
Joe Jin [Mon, 19 Oct 2015 05:37:17 +0000 (13:37 +0800)]
xen-netfront: update num_queues to real created

[ Upstream commit ca88ea1247dfee094e2467a3578eaec9bdf0833a ]

Sometimes xennet_create_queues() may failed to created all requested
queues, we need to update num_queues to real created to avoid NULL
pointer dereference.

Signed-off-by: Joe Jin <>
Cc: Boris Ostrovsky <>
Cc: Konrad Rzeszutek Wilk <>
Cc: Wei Liu <>
Cc: Ian Campbell <>
Cc: David S. Miller <>
Reviewed-by: Boris Ostrovsky <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoxen-netfront: respect user provided max_queues
Wei Liu [Thu, 10 Sep 2015 10:18:58 +0000 (11:18 +0100)]
xen-netfront: respect user provided max_queues

[ Upstream commit 32a844056fd43dda647e1c3c6b9983bdfa04d17d ]

Originally that parameter was always reset to num_online_cpus during
module initialisation, which renders it useless.

The fix is to only set max_queues to num_online_cpus when user has not
provided a value.

Signed-off-by: Wei Liu <>
Cc: David Vrabel <>
Reviewed-by: David Vrabel <>
Tested-by: David Vrabel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoxen-netback: respect user provided max_queues
Wei Liu [Thu, 10 Sep 2015 10:18:57 +0000 (11:18 +0100)]
xen-netback: respect user provided max_queues

[ Upstream commit 4c82ac3c37363e8c4ded6a5fe1ec5fa756b34df3 ]

Originally that parameter was always reset to num_online_cpus during
module initialisation, which renders it useless.

The fix is to only set max_queues to num_online_cpus when user has not
provided a value.

Reported-by: Johnny Strom <>
Signed-off-by: Wei Liu <>
Reviewed-by: David Vrabel <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoteam: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid
Ido Schimmel [Mon, 18 Jan 2016 15:30:22 +0000 (17:30 +0200)]
team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid

[ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ]

We can't be within an RCU read-side critical section when deleting
VLANs, as underlying drivers might sleep during the hardware operation.
Therefore, replace the RCU critical section with a mutex. This is
consistent with team_vlan_rx_add_vid.

Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
Acked-by: Jiri Pirko <>
Signed-off-by: Ido Schimmel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoppp, slip: Validate VJ compression slot parameters completely
Ben Hutchings [Sun, 1 Nov 2015 16:22:53 +0000 (16:22 +0000)]
ppp, slip: Validate VJ compression slot parameters completely

[ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoisdn_ppp: Add checks for allocation failure in isdn_ppp_open()
Ben Hutchings [Sun, 1 Nov 2015 16:21:24 +0000 (16:21 +0000)]
isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

[ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ]

Compile-tested only.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoipv6: update skb->csum when CE mark is propagated
Eric Dumazet [Fri, 15 Jan 2016 12:56:56 +0000 (04:56 -0800)]
ipv6: update skb->csum when CE mark is propagated

[ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ]

When a tunnel decapsulates the outer header, it has to comply
with RFC 6080 and eventually propagate CE mark into inner header.

It turns out IP6_ECN_set_ce() does not correctly update skb->csum
for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure"
messages and stack traces.

Signed-off-by: Eric Dumazet <>
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agonet: bpf: reject invalid shifts
Rabin Vincent [Tue, 12 Jan 2016 19:17:08 +0000 (20:17 +0100)]
net: bpf: reject invalid shifts

[ Upstream commit 229394e8e62a4191d592842cf67e80c62a492937 ]

On ARM64, a BUG() is triggered in the eBPF JIT if a filter with a
constant shift that can't be encoded in the immediate field of the
UBFM/SBFM instructions is passed to the JIT.  Since these shifts
amounts, which are negative or >= regsize, are invalid, reject them in
the eBPF verifier and the classic BPF filter checker, for all

Signed-off-by: Rabin Vincent <>
Acked-by: Alexei Starovoitov <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agophonet: properly unshare skbs in phonet_rcv()
Eric Dumazet [Tue, 12 Jan 2016 16:58:00 +0000 (08:58 -0800)]
phonet: properly unshare skbs in phonet_rcv()

[ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ]

Ivaylo Dimitrov reported a regression caused by commit 7866a621043f
("dev: add per net_device packet type chains").

skb->dev becomes NULL and we crash in __netif_receive_skb_core().

Before above commit, different kind of bugs or corruptions could happen
without major crash.

But the root cause is that phonet_rcv() can queue skb without checking
if skb is shared or not.

Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests.

Reported-by: Ivaylo Dimitrov <>
Tested-by: Ivaylo Dimitrov <>
Signed-off-by: Eric Dumazet <>
Cc: Remi Denis-Courmont <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agobonding: Prevent IPv6 link local address on enslaved devices
Karl Heiss [Mon, 11 Jan 2016 13:28:43 +0000 (08:28 -0500)]
bonding: Prevent IPv6 link local address on enslaved devices

[ Upstream commit 03d84a5f83a67e692af00a3d3901e7820e3e84d5 ]

Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
undoes the fix provided by commit c2edacf80e15 ("bonding / ipv6: no addrconf
for slaves separately from master") by effectively setting the slave flag
after the slave has been opened.  If the slave comes up quickly enough, it
will go through the IPv6 addrconf before the slave flag has been set and
will get a link local IPv6 address.

In order to ensure that addrconf knows to ignore the slave devices on state
change, set IFF_SLAVE before dev_open() during bonding enslavement.

Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Signed-off-by: Karl Heiss <>
Signed-off-by: Jay Vosburgh <>
Reviewed-by: Jarod Wilson <>
Signed-off-by: Andy Gospodarek <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agotcp_yeah: don't set ssthresh below 2
Neal Cardwell [Mon, 11 Jan 2016 18:42:43 +0000 (13:42 -0500)]
tcp_yeah: don't set ssthresh below 2

[ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ]

For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno
and CUBIC, per RFC 5681 (equation 4).

tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh
value if the intended reduction is as big or bigger than the current
cwnd. Congestion control modules should never return a zero or
negative ssthresh. A zero ssthresh generally results in a zero cwnd,
causing the connection to stall. A negative ssthresh value will be
interpreted as a u32 and will set a target cwnd for PRR near 4

Oleksandr Natalenko reported that a system using tcp_yeah with ECN
could see a warning about a prior_cwnd of 0 in
tcp_cwnd_reduction(). Testing verified that this was due to
tcp_yeah_ssthresh() misbehaving in this way.

Reported-by: Oleksandr Natalenko <>
Signed-off-by: Neal Cardwell <>
Signed-off-by: Yuchung Cheng <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoipv6: tcp: add rcu locking in tcp_v6_send_synack()
Eric Dumazet [Fri, 8 Jan 2016 17:35:51 +0000 (09:35 -0800)]
ipv6: tcp: add rcu locking in tcp_v6_send_synack()

[ Upstream commit 3e4006f0b86a5ae5eb0e8215f9a9e1db24506977 ]

When first SYNACK is sent, we already hold rcu_read_lock(), but this
is not true if a SYNACK is retransmitted, as a timer (soft) interrupt
does not hold rcu_read_lock()

Fixes: 45f6fad84cc30 ("ipv6: add complete rcu protection around np->opt")
Reported-by: Dave Jones <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agonet: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory
Sasha Levin [Thu, 7 Jan 2016 19:52:43 +0000 (14:52 -0500)]
net: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory

[ Upstream commit 320f1a4a175e7cd5d3f006f92b4d4d3e2cbb7bb5 ]

proc_dostring() needs an initialized destination string, while the one
provided in proc_sctp_do_hmac_alg() contains stack garbage.

Thus, writing to cookie_hmac_alg would strlen() that garbage and end up
accessing invalid memory.

Fixes: 3c68198e7 ("sctp: Make hmac algorithm selection for cookie generation dynamic")
Signed-off-by: Sasha Levin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agovxlan: fix test which detect duplicate vxlan iface
Nicolas Dichtel [Thu, 7 Jan 2016 10:26:53 +0000 (11:26 +0100)]
vxlan: fix test which detect duplicate vxlan iface

[ Upstream commit 07b9b37c227cb8d88d478b4a9c5634fee514ede1 ]

When a vxlan interface is created, the driver checks that there is not
another vxlan interface with the same properties. To do this, it checks
the existing vxlan udp socket. Since commit 1c51a9159dde, the creation of
the vxlan socket is done only when the interface is set up, thus it breaks
that test.

$ ip l a vxlan10 type vxlan id 10 group dev eth0 dstport 0
$ ip l a vxlan11 type vxlan id 10 group dev eth0 dstport 0
$ ip -br l | grep vxlan
vxlan10          DOWN           f2:55:1c:6a:fb:00 <BROADCAST,MULTICAST>
vxlan11          DOWN           7a:cb:b9:38:59:0d <BROADCAST,MULTICAST>

Instead of checking sockets, let's loop over the vxlan iface list.

Fixes: 1c51a9159dde ("vxlan: fix race caused by dropping rtnl_unlock")
Reported-by: Thomas Faivre <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agonet: possible use after free in dst_release
Francesco Ruggeri [Wed, 6 Jan 2016 08:18:48 +0000 (00:18 -0800)]
net: possible use after free in dst_release

[ Upstream commit 07a5d38453599052aff0877b16bb9c1585f08609 ]

dst_release should not access dst->flags after decrementing
__refcnt to 0. The dst_entry may be in dst_busy_list and
dst_gc_task may dst_destroy it before dst_release gets a chance
to access dst->flags.

Fixes: d69bbf88c8d0 ("net: fix a race in dst_release()")
Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
Signed-off-by: Francesco Ruggeri <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agonet: sched: fix missing free per cpu on qstats
John Fastabend [Tue, 5 Jan 2016 17:11:36 +0000 (09:11 -0800)]
net: sched: fix missing free per cpu on qstats

[ Upstream commit 73c20a8b7245273125cfe92c4b46e6fdb568a801 ]

When a qdisc is using per cpu stats (currently just the ingress
qdisc) only the bstats are being freed. This also free's the qstats.

Fixes: b0ab6f92752b9f9d8 ("net: sched: enable per cpu qstats")
Signed-off-by: John Fastabend <>
Acked-by: Eric Dumazet <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agonet: filter: make JITs zero A for SKF_AD_ALU_XOR_X
Rabin Vincent [Tue, 5 Jan 2016 15:23:07 +0000 (16:23 +0100)]
net: filter: make JITs zero A for SKF_AD_ALU_XOR_X

[ Upstream commit 55795ef5469290f89f04e12e662ded604909e462 ]

The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
instructions since it XORs A with X while all the others replace A with
some loaded value.  All the BPF JITs fail to clear A if this is used as
the first instruction in a filter.  This was found using american fuzzy

Add a helper to determine if A needs to be cleared given the first
instruction in a filter, and use this in the JITs.  Except for ARM, the
rest have only been compile-tested.

Fixes: 3480593131e0 ("net: filter: get rid of BPF_S_* enum")
Signed-off-by: Rabin Vincent <>
Acked-by: Daniel Borkmann <>
Acked-by: Alexei Starovoitov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agobridge: Only call /sbin/bridge-stp for the initial network namespace
Hannes Frederic Sowa [Tue, 5 Jan 2016 09:46:00 +0000 (10:46 +0100)]
bridge: Only call /sbin/bridge-stp for the initial network namespace

[ Upstream commit ff62198553e43cdffa9d539f6165d3e83f8a42bc ]

[I stole this patch from Eric Biederman. He wrote:]

> There is no defined mechanism to pass network namespace information
> into /sbin/bridge-stp therefore don't even try to invoke it except
> for bridge devices in the initial network namespace.
> It is possible for unprivileged users to cause /sbin/bridge-stp to be
> invoked for any network device name which if /sbin/bridge-stp does not
> guard against unreasonable arguments or being invoked twice on the
> same network device could cause problems.

[Hannes: changed patch using netns_eq]

Cc: Eric W. Biederman <>
Signed-off-by: Eric W. Biederman <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agounix: properly account for FDs passed over unix sockets
willy tarreau [Sun, 10 Jan 2016 06:54:56 +0000 (07:54 +0100)]
unix: properly account for FDs passed over unix sockets

[ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]

It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.

This change addresses this problem by keeping track of the number of FDs
in flight per user and preventing non-privileged processes from having
more FDs in flight than their configured FD limit.

Reported-by: Tetsuo Handa <>
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: Willy Tarreau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoconnector: bump skb->users before callback invocation
Florian Westphal [Thu, 31 Dec 2015 13:26:33 +0000 (14:26 +0100)]
connector: bump skb->users before callback invocation

[ Upstream commit 55285bf09427c5abf43ee1d54e892f352092b1f1 ]

Dmitry reports memleak with syskaller program.
Problem is that connector bumps skb usecount but might not invoke callback.

So move skb_get to where we invoke the callback.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Florian Westphal <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agosctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close
Xin Long [Tue, 29 Dec 2015 09:49:25 +0000 (17:49 +0800)]
sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close

[ Upstream commit 068d8bd338e855286aea54e70d1c101569284b21 ]

In sctp_close, sctp_make_abort_user may return NULL because of memory
allocation failure. If this happens, it will bypass any state change
and never free the assoc. The assoc has no chance to be freed and it
will be kept in memory with the state it had even after the socket is
closed by sctp_close().

So if sctp_make_abort_user fails to allocate memory, we should abort
the asoc via sctp_primitive_ABORT as well. Just like the annotation in
sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said,
"Even if we can't send the ABORT due to low memory delete the TCB.
This is a departure from our typical NOMEM handling".

But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would
dereference the chunk pointer, and system crash. So we should add
SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other
places where it adds SCTP_CMD_REPLY cmd.

Signed-off-by: Xin Long <>
Acked-by: Marcelo Ricardo Leitner <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoipv6/addrlabel: fix ip6addrlbl_get()
Andrey Ryabinin [Mon, 21 Dec 2015 09:54:45 +0000 (12:54 +0300)]
ipv6/addrlabel: fix ip6addrlbl_get()

[ Upstream commit e459dfeeb64008b2d23bdf600f03b3605dbb8152 ]

ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.

Fix this by inverting ip6addrlbl_hold() check.

Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
Signed-off-by: Andrey Ryabinin <>
Reviewed-by: Cong Wang <>
Acked-by: YOSHIFUJI Hideaki <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoveth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
Vijay Pandurangan [Fri, 18 Dec 2015 19:34:59 +0000 (14:34 -0500)]
veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ]

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
<e314dbdc1c0dc6a548ecf> ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.

Co-authored-by: Evan Jones <>
Signed-off-by: Evan Jones <>
Cc: Nicolas Dichtel <>
Cc: Phil Sutter <>
Cc: Toshiaki Makita <>
Signed-off-by: Vijay Pandurangan <>
Acked-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Sasha Levin <>
4 years agoX.509: Don't strip leading 00's from key ID when constructing key description
David Howells [Fri, 25 Sep 2015 15:31:46 +0000 (16:31 +0100)]
X.509: Don't strip leading 00's from key ID when constructing key description

[ Upstream commit e7c87bef7de2417b219d4dbfe8d33a0098a8df54 ]

Don't strip leading zeros from the crypto key ID when using it to construct
the struct key description as the signature in kernels up to and including
4.2 matched this aspect of the key.  This means that 1 in 256 keys won't
actually match if their key ID begins with 00.

The key ID is stored in the module signature as binary and so must be
converted to text in order to invoke request_key() - but it isn't stripped
at this point.

Something like this is likely to be observed in dmesg when the key is loaded:

[    1.572423] Loaded X.509 cert 'Build time autogenerated kernel
    key: 62a7c3d2da278be024da4af8652c071f3fea33'

followed by this when we try and use it:

  [    1.646153] Request for unknown module key 'Build time autogenerated
    kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11

The 'Loaded' line should show an extra '00' on the front of the hex string.

This problem should not affect 4.3-rc1 and onwards because there the key
should be matched on one of its auxiliary identities rather than the key
struct's description string.

Reported-by: Arjan van de Ven <>
Reported-by: Andy Whitcroft <>
Signed-off-by: David Howells <>
Signed-off-by: Sasha Levin <>
4 years agoradix-tree: fix oops after radix_tree_iter_retry
Konstantin Khlebnikov [Fri, 5 Feb 2016 23:37:01 +0000 (15:37 -0800)]
radix-tree: fix oops after radix_tree_iter_retry

[ Upstream commit 732042821cfa106b3c20b9780e4c60fee9d68900 ]

Helper radix_tree_iter_retry() resets next_index to the current index.
In following radix_tree_next_slot current chunk size becomes zero.  This
isn't checked and it tries to dereference null pointer in slot.

Tagged iterator is fine because retry happens only at slot 0 where tag
bitmask in iter->tags is filled with single bit.

Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup")
Signed-off-by: Konstantin Khlebnikov <>
Cc: Matthew Wilcox <>
Cc: Hugh Dickins <>
Cc: Ohad Ben-Cohen <>
Cc: Jeremiah Mahler <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agomm: replace vma_lock_anon_vma with anon_vma_lock_read/write
Konstantin Khlebnikov [Fri, 5 Feb 2016 23:36:50 +0000 (15:36 -0800)]
mm: replace vma_lock_anon_vma with anon_vma_lock_read/write

[ Upstream commit 12352d3cae2cebe18805a91fab34b534d7444231 ]

Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if
anon_vma appeared between lock and unlock.  We have to check anon_vma
first or call anon_vma_prepare() to be sure that it's here.  There are
only few users of these legacy helpers.  Let's get rid of them.

This patch fixes anon_vma lock imbalance in validate_mm().  Write lock
isn't required here, read lock is enough.

And reorders expand_downwards/expand_upwards: security_mmap_addr() and
wrapping-around check don't have to be under anon vma lock.

Signed-off-by: Konstantin Khlebnikov <>
Reported-by: Dmitry Vyukov <>
Acked-by: Kirill A. Shutemov <>
Cc: Andrea Arcangeli <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agoocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup
xuejiufei [Fri, 5 Feb 2016 23:36:47 +0000 (15:36 -0800)]
ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup

[ Upstream commit c95a51807b730e4681e2ecbdfd669ca52601959e ]

When recovery master down, dlm_do_local_recovery_cleanup() only remove
the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
Which will make umount thread falling in dead loop migrating $RECOVERY
to the dead node.

Signed-off-by: xuejiufei <>
Reviewed-by: Joseph Qi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Junxiao Bi <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agodump_stack: avoid potential deadlocks
Eric Dumazet [Fri, 5 Feb 2016 23:36:16 +0000 (15:36 -0800)]
dump_stack: avoid potential deadlocks

[ Upstream commit d7ce36924344ace0dbdc855b1206cacc46b36d45 ]

Some servers experienced fatal deadlocks because of a combination of
bugs, leading to multiple cpus calling dump_stack().

The checksumming bug was fixed in commit 34ae6a1aa054 ("ipv6: update
skb->csum when CE mark is propagated").

The second problem is a faulty locking in dump_stack()

CPU1 runs in process context and calls dump_stack(), grabs dump_lock.

   CPU2 receives a TCP packet under softirq, grabs socket spinlock, and
   call dump_stack() from netdev_rx_csum_fault().

   dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since
   dump_lock is owned by CPU1

While dumping its stack, CPU1 is interrupted by a softirq, and happens
to process a packet for the TCP socket locked by CPU2.

CPU1 spins forever in spin_lock() : deadlock

Stack trace on CPU1 looked like :

    NMI backtrace for cpu 1
    RIP: _raw_spin_lock+0x25/0x30
    Call Trace:

Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
Signed-off-by: Eric Dumazet <>
Cc: Alex Thorlton <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agodrm/dp/mst: Calculate MST PBN with 31.32 fixed point
Harry Wentland [Fri, 22 Jan 2016 22:07:26 +0000 (17:07 -0500)]
drm/dp/mst: Calculate MST PBN with 31.32 fixed point

[ Upstream commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 ]

Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.

This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.

Signed-off-by: Harry Wentland <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Sasha Levin <>
4 years agodrm: Add drm_fixp_from_fraction and drm_fixp2int_ceil
Harry Wentland [Fri, 22 Jan 2016 22:07:25 +0000 (17:07 -0500)]
drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil

[ Upstream commit 64566b5e767f9bc3161055ca1b443a51afb52aad ]

drm_fixp_from_fraction allows us to create a fixed point directly
from a fraction, rather than creating fixed point values and dividing
later. This avoids overflow of our 64 bit value for large numbers.

drm_fixp2int_ceil allows us to return the ceiling of our fixed point

[airlied: squash Jordan's fix]
32-bit-build-fix: Jordan Lazare <>
Signed-off-by: Harry Wentland <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Sasha Levin <>
4 years agodrm: fix missing reference counting decrease
Insu Yun [Mon, 1 Feb 2016 16:08:29 +0000 (11:08 -0500)]
drm: fix missing reference counting decrease

[ Upstream commit dabe19540af9e563d526113bb102e1b9b9fa73f9 ]

In drm_dp_mst_allocate_vcpi, it returns true in two paths,
but in one path, there is no reference couting decrease.

Signed-off-by: Insu Yun <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Sasha Levin <>
4 years agoARM: nomadik: set up MCDATDIR2
Linus Walleij [Sat, 27 Sep 2014 13:45:02 +0000 (15:45 +0200)]
ARM: nomadik: set up MCDATDIR2

[ Upstream commit 43c4034963d6e838d971cbe59bfe84ae6e8370e6 ]

This extra data line for high-speed MMC transfers was unrouted,
set it up properly in the dtsi file.

Signed-off-by: Linus Walleij <>
Signed-off-by: Sasha Levin <>
4 years ago[media] saa7134-alsa: Only frees registered sound cards
Mauro Carvalho Chehab [Thu, 4 Feb 2016 17:59:43 +0000 (15:59 -0200)]
[media] saa7134-alsa: Only frees registered sound cards

[ Upstream commit ac75fe5d8fe4a0bf063be18fb29684405279e79e ]

That prevents this bug:
[ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540
[ 2382.270013] IP: [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] PGD 0
[ 2382.270013] Oops: 0002 [#1] SMP
[ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops]
[ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4
[ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012  05/14/2008
[ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000
[ 2382.270013] RIP: 0010:[<ffffffffa01fe616>]  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] RSP: 0018:ffff88003c767ea0  EFLAGS: 00010286
[ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260
[ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0
[ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412
[ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8
[ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0
[ 2382.270013] FS:  00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000
[ 2382.270013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0
[ 2382.270013] Stack:
[ 2382.270013]  000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8
[ 2382.270013]  ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0
[ 2382.270013]  ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c
[ 2382.270013] Call Trace:
[ 2382.270013]  [<ffffffffa049889d>] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa]
[ 2382.270013]  [<ffffffff8111079c>] SyS_delete_module+0x19c/0x1f0
[ 2382.270013]  [<ffffffff8170fc2e>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d
[ 2382.270013] RIP  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013]  RSP <ffff88003c767ea0>
[ 2382.270013] CR2: 0000000000000540

Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: timer: Fix leftover link at closing
Takashi Iwai [Thu, 4 Feb 2016 16:06:13 +0000 (17:06 +0100)]
ALSA: timer: Fix leftover link at closing

[ Upstream commit 094fd3be87b0f102589e2d5c3fa5d06b7e20496d ]

In ALSA timer core, the active timer instance is managed in
active_list linked list.  Each element is added / removed dynamically
at timer start, stop and in timer interrupt.  The problem is that
snd_timer_interrupt() has a thinko and leaves the element in
active_list when it's the last opened element.  This eventually leads
to list corruption or use-after-free error.

This hasn't been revealed because we used to delete the list forcibly
in snd_timer_stop() in the past.  However, the recent fix avoids the
double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link
corruption due to double start or stop]), and this leak hits reality.

This patch fixes the link management in snd_timer_interrupt().  Now it
simply unlinks no matter which stream is.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: timer: Fix double unlink of active_list
Takashi Iwai [Wed, 13 Jan 2016 20:35:06 +0000 (21:35 +0100)]
ALSA: timer: Fix double unlink of active_list

[ Upstream commit ee8413b01045c74340aa13ad5bdf905de32be736 ]

ALSA timer instance object has a couple of linked lists and they are
unlinked unconditionally at snd_timer_stop().  Meanwhile
snd_timer_interrupt() unlinks it, but it calls list_del() which leaves
the element list itself unchanged.  This ends up with unlinking twice,
and it was caught by syzkaller fuzzer.

The fix is to use list_del_init() variant properly there, too.

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years ago[media] tda1004x: only update the frontend properties if locked
Mauro Carvalho Chehab [Wed, 3 Feb 2016 19:33:48 +0000 (17:33 -0200)]
[media] tda1004x: only update the frontend properties if locked

[ Upstream commit e8beb02343e7582980c6705816cd957cf4f74c7a ]

The tda1004x was updating the properties cache before locking.
If the device is not locked, the data at the registers are just
random values with no real meaning.

This caused the driver to fail with libdvbv5, as such library
calls GET_PROPERTY from time to time, in order to return the
DVB stats.

Tested with a saa7134 card 78:
ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862

Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Sasha Levin <>
4 years agoxhci: Fix list corruption in urb dequeue at host removal
Mathias Nyman [Tue, 26 Jan 2016 15:50:12 +0000 (17:50 +0200)]
xhci: Fix list corruption in urb dequeue at host removal

[ Upstream commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 ]

xhci driver frees data for all devices, both usb2 and and usb3 the
first time usb_remove_hcd() is called, including td_list and and xhci_ring

When usb_remove_hcd() is called a second time for the second xhci bus it
will try to dequeue all pending urbs, and touches td_list which is already
freed for that endpoint.

Cc: <>
Reported-by: Joe Lawrence <>
Tested-by: Joe Lawrence <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agousb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms
Lu Baolu [Tue, 26 Jan 2016 15:50:08 +0000 (17:50 +0200)]
usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms

[ Upstream commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 ]

Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.

Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agousb: xhci: set SSIC port unused only if xhci_suspend succeeds
Lu Baolu [Tue, 26 Jan 2016 15:50:07 +0000 (17:50 +0200)]
usb: xhci: set SSIC port unused only if xhci_suspend succeeds

[ Upstream commit 92149c930cce1865d0d4aca2ab07c2b4b197b418 ]

XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers
in some Intel SoC chips.  With this quirk applied, SSIC port is set
to "unused" prior to xhci_suspend(). This may cause problem if host
fails to suspend.  In this case, the port is set to unused without
host further entering D3, and the port will not be usable anymore.

Signed-off-by: Zhuang Jin Can <>
Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agousb: xhci: add a quirk bit for ssic port unused
Lu Baolu [Tue, 26 Jan 2016 15:50:06 +0000 (17:50 +0200)]
usb: xhci: add a quirk bit for ssic port unused

[ Upstream commit 7e70cbffe236721051bbaff965e477df06dcb190 ]

Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround
for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci:
Workaround to get D3 working in Intel xHCI") share a single quirk bit
XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and
might happen on different hardwares. Need to separate them by adding a
quirk bit for the later.

Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agousb: xhci: handle both SSIC ports in PME stuck quirk
Lu Baolu [Tue, 26 Jan 2016 15:50:05 +0000 (17:50 +0200)]
usb: xhci: handle both SSIC ports in PME stuck quirk

[ Upstream commit fa89537783cb442263fa5a14df6c7693eaf32f11 ]

Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI")
adds a workaround for a limitation of PME storm caused by SSIC port in
some Intel SoCs. This commit only handled one SSIC port, while there
are actually two SSIC ports in the chips. This patch handles both SSIC
ports. Without this fix, users still see PME storm.

Cc: # v4.2+
Signed-off-by: Zhuang Jin Can <>
Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agoxhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM
Tomer Barletz [Mon, 21 Sep 2015 14:46:11 +0000 (17:46 +0300)]
xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM

commit 2b7627b73e81e5d23d5ae1490fe8e690af86e053 upstream.

xhci_pme_quirk() is only used when CONFIG_PM is defined.
Compiling a kernel without PM complains about this function

[reworded commit message -Mathias]
Signed-off-by: Tomer Barletz <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci: Workaround to get D3 working in Intel xHCI
Rajmohan Mani [Tue, 21 Jul 2015 14:20:26 +0000 (17:20 +0300)]
xhci: Workaround to get D3 working in Intel xHCI

[ Upstream commit abce329c27b315cfc01be1a305ee976ee13ed4cf ]

The xHCI in Intel CherryView / Braswell Platform requires
a driver workaround to get xHCI D3 working. Without this
workaround, xHCI might not enter D3.

Workaround is to configure SSIC PORT as "unused" before D3
entry and "used" after D3 exit. This is done through a
vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset
0x883c), in xhci suspend / resume callbacks.

Verified xHCI D3 works fine in CherryView / Braswell platform.

Signed-off-by: Rajmohan Mani <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agoxhci: call BIOS workaround to enable runtime suspend on Intel Braswell
Mathias Nyman [Tue, 21 Jul 2015 14:20:25 +0000 (17:20 +0300)]
xhci: call BIOS workaround to enable runtime suspend on Intel Braswell

[ Upstream commit c3c5819a350952439c3198aa46581f9e4c46557f ]

Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled
xhci from going to D3 state in runtime suspend. Driver needs to verify
it can deal with the hw by calling an ACPI _DSM method to get D3 enabled.

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agoradix-tree: fix race in gang lookup
Matthew Wilcox [Wed, 3 Feb 2016 00:57:52 +0000 (16:57 -0800)]
radix-tree: fix race in gang lookup

[ Upstream commit 46437f9a554fbe3e110580ca08ab703b59f2f95a ]

If the indirect_ptr bit is set on a slot, that indicates we need to redo
the lookup.  Introduce a new function radix_tree_iter_retry() which
forces the loop to retry the lookup by setting 'slot' to NULL and
turning the iterator back to point at the problematic entry.

This is a pretty rare problem to hit at the moment; the lookup has to
race with a grow of the radix tree from a height of 0.  The consequences
of hitting this race are that gang lookup could return a pointer to a
radix_tree_node instead of a pointer to whatever the user had inserted
in the tree.

Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
Signed-off-by: Matthew Wilcox <>
Cc: Hugh Dickins <>
Cc: Ohad Ben-Cohen <>
Cc: Konstantin Khlebnikov <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agodrivers/scsi/sg.c: mark VMA as VM_IO to prevent migration
Kirill A. Shutemov [Wed, 3 Feb 2016 00:57:35 +0000 (16:57 -0800)]
drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration

[ Upstream commit 461c7fa126794157484dca48e88effa4963e3af3 ]

Reduced testcase:

    #include <fcntl.h>
    #include <unistd.h>
    #include <sys/mman.h>
    #include <numaif.h>

    #define SIZE 0x2000

    int main()
        int fd;
        void *p;

        fd = open("/dev/sg0", O_RDWR);
        p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0);
        mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE);
        return 0;

We shouldn't try to migrate pages in sg VMA as we don't have a way to
update Sg_scatter_hold::pages accordingly from mm core.

Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not

Signed-off-by: Kirill A. Shutemov <>
Reported-by: Dmitry Vyukov <>
Acked-by: Vlastimil Babka <>
Cc: Doug Gilbert <>
Cc: David Rientjes <>
Cc: Naoya Horiguchi <>
Cc: "Kirill A. Shutemov" <>
Cc: Shiraz Hashim <>
Cc: Hugh Dickins <>
Cc: Sasha Levin <>
Cc: syzkaller <>
Cc: Kostya Serebryany <>
Cc: Alexander Potapenko <>
Cc: James Bottomley <>
Cc: <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: seq: Fix lockdep warnings due to double mutex locks
Takashi Iwai [Wed, 3 Feb 2016 07:32:44 +0000 (08:32 +0100)]
ALSA: seq: Fix lockdep warnings due to double mutex locks

[ Upstream commit 7f0973e973cd74aa40747c9d38844560cd184ee8 ]

The port subscription code uses double mutex locks for source and
destination ports, and this may become racy once when wrongly set up.
It leads to lockdep warning splat, typically triggered by fuzzer like
syzkaller, although the actual deadlock hasn't been seen, so far.

This patch simplifies the handling by reducing to two single locks, so
that no lockdep warning will be trigger any longer.

By splitting to two actions, a still-in-progress element shall be
added in one list while handling another.  For ignoring this element,
a new check is added in deliver_to_subscribers().

Along with it, the code to add/remove the subscribers list element was
cleaned up and refactored.

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: rawmidi: Fix race at copying & updating the position
Takashi Iwai [Wed, 3 Feb 2016 13:41:22 +0000 (14:41 +0100)]
ALSA: rawmidi: Fix race at copying & updating the position

[ Upstream commit 81f577542af15640cbcb6ef68baa4caa610cbbfc ]

The rawmidi read and write functions manage runtime stream status
such as runtime->appl_ptr and runtime->avail.  These point where to
copy the new data and how many bytes have been copied (or to be
read).  The problem is that rawmidi read/write call copy_from_user()
or copy_to_user(), and the runtime spinlock is temporarily unlocked
and relocked while copying user-space.  Since the current code
advances and updates the runtime status after the spin unlock/relock,
the copy and the update may be asynchronous, and eventually
runtime->avail might go to a negative value when many concurrent
accesses are done.  This may lead to memory corruption in the end.

For fixing this race, in this patch, the status update code is
performed in the same lock before the temporary unlock.  Also, the
spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
protecting more properly during the whole operation.

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: rawmidi: Make snd_rawmidi_transmit() race-free
Takashi Iwai [Sun, 31 Jan 2016 10:57:41 +0000 (11:57 +0100)]
ALSA: rawmidi: Make snd_rawmidi_transmit() race-free

[ Upstream commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 ]

A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: hda - Add fixup for Mac Mini 7,1 model
Takashi Iwai [Wed, 3 Feb 2016 11:32:51 +0000 (12:32 +0100)]
ALSA: hda - Add fixup for Mac Mini 7,1 model

[ Upstream commit 2154cc0e2d4ae15132d005d17e473327c70c9a06 ]

Mac Mini 7,1 model with CS4208 codec reports the headphone jack
detection wrongly in an inverted way.  Moreover, the advertised pins
for the audio input and SPDIF output have actually no jack detection.

This patch addresses these issues.  The inv_jack_detect flag is set
for fixing the headphone jack detection, and the pin configs for audio
input and SPDIF output are marked as non-detectable.

Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agodrm/radeon: mask out WC from BO on unsupported arches
Oded Gabbay [Sat, 30 Jan 2016 05:59:33 +0000 (07:59 +0200)]
drm/radeon: mask out WC from BO on unsupported arches

[ Upstream commit c5244987394648913ae1a03879c58058a2fc2cee ]

Reviewed-by: Christian König <>
Reviewed-by: Michel Dänzer <>
Signed-off-by: Oded Gabbay <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Sasha Levin <>
4 years agodrm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC
Michel Dänzer [Thu, 5 Nov 2015 08:25:27 +0000 (17:25 +0900)]
drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC

[ Upstream commit a28bbd5824d4a2af98de45b300ab8d8fb39739fc ]

Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.

Reviewed-by: Christian König <>
Signed-off-by: Michel Dänzer <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Sasha Levin <>
4 years agodrm: add helper to check for wc memory support
Dave Airlie [Sat, 30 Jan 2016 05:59:32 +0000 (07:59 +0200)]
drm: add helper to check for wc memory support

[ Upstream commit 4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc ]

Reviewed-by: Christian König <>
Reviewed-by: Michel Dänzer <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Oded Gabbay <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: timer: Fix link corruption due to double start or stop
Takashi Iwai [Sat, 30 Jan 2016 22:09:08 +0000 (23:09 +0100)]
ALSA: timer: Fix link corruption due to double start or stop

[ Upstream commit f784beb75ce82f4136f8a0960d3ee872f7109e09 ]

Although ALSA timer code got hardening for races, it still causes
use-after-free error.  This is however rather a corrupted linked list,
not actually the concurrent accesses.  Namely, when timer start is
triggered twice, list_add_tail() is called twice, too.  This ends
up with the link corruption and triggers KASAN error.

The simplest fix would be replacing list_add_tail() with
list_move_tail(), but fundamentally it's the problem that we don't
check the double start/stop correctly.  So, the right fix here is to
add the proper checks to snd_timer_start() and snd_timer_stop() (and
their variants).

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: timer: Code cleanup
Takashi Iwai [Thu, 14 Jan 2016 16:01:46 +0000 (17:01 +0100)]
ALSA: timer: Code cleanup

[ Upstream commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 ]

This is a minor code cleanup without any functional changes:
- Kill keep_flag argument from _snd_timer_stop(), as all callers pass
  only it false.
- Remove redundant NULL check in _snd_timer_stop().

Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: timer: Harden slave timer list handling
Takashi Iwai [Thu, 14 Jan 2016 15:30:58 +0000 (16:30 +0100)]
ALSA: timer: Harden slave timer list handling

[ Upstream commit b5a663aa426f4884c71cd8580adae73f33570f0d ]

A slave timer instance might be still accessible in a racy way while
operating the master instance as it lacks of locking.  Since the
master operation is mostly protected with timer->lock, we should cope
with it while changing the slave instance, too.  Also, some linked
lists (active_list and ack_list) of slave instances aren't unlinked
immediately at stopping or closing, and this may lead to unexpected

This patch tries to address these issues.  It adds spin lock of
timer->lock (either from master or slave, which is equivalent) in a
few places.  For avoiding a deadlock, we ensure that the global
slave_active_lock is always locked at first before each timer lock.

Also, ack and active_list of slave instances are properly unlinked at
snd_timer_stop() and snd_timer_close().

Last but not least, remove the superfluous call of _snd_timer_stop()
at removing slave links.  This is a noop, and calling it may confuse
readers wrt locking.  Further cleanup will follow in a later patch.

Actually we've got reports of use-after-free by syzkaller fuzzer, and
this hopefully fixes these issues.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: seq: Fix yet another races among ALSA timer accesses
Takashi Iwai [Sat, 30 Jan 2016 22:30:25 +0000 (23:30 +0100)]
ALSA: seq: Fix yet another races among ALSA timer accesses

[ Upstream commit 2cdc7b636d55cbcf42e1e6c8accd85e62d3e9ae8 ]

ALSA sequencer may open/close and control ALSA timer instance
dynamically either via sequencer events or direct ioctls.  These are
done mostly asynchronously, and it may call still some timer action
like snd_timer_start() while another is calling snd_timer_close().
Since the instance gets removed by snd_timer_close(), it may lead to
a use-after-free.

This patch tries to address such a race by protecting each
snd_timer_*() call via the existing spinlock and also by avoiding the
access to timer during close call.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: pcm: Fix potential deadlock in OSS emulation
Takashi Iwai [Sun, 31 Jan 2016 09:32:37 +0000 (10:32 +0100)]
ALSA: pcm: Fix potential deadlock in OSS emulation

[ Upstream commit b248371628aad599a48540962f6b85a21a8a0c3f ]

There are potential deadlocks in PCM OSS emulation code while
accessing read/write and mmap concurrently.  This comes from the
infamous mmap_sem usage in copy_from/to_user().  Namely,

   snd_pcm_oss_write() ->
     &runtime->oss.params_lock ->
        copy_to_user() ->
  mmap() ->
    &mm->mmap_sem ->
      snd_pcm_oss_mmap() ->

Since we can't avoid taking params_lock from mmap code path, use
trylock variant and aborts with -EAGAIN as a workaround of this AB/BA

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check
Takashi Iwai [Mon, 1 Feb 2016 11:04:55 +0000 (12:04 +0100)]
ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check

[ Upstream commit cc85f7a634cfaf9f0713c6aa06d08817424db37a ]

NULL user-space buffer can be passed even in a normal path, thus it's
not good to spew a kernel warning with stack trace at each time.
Just drop snd_BUG_ON() macro usage there.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: seq: Fix race at closing in virmidi driver
Takashi Iwai [Mon, 1 Feb 2016 11:06:42 +0000 (12:06 +0100)]
ALSA: seq: Fix race at closing in virmidi driver

[ Upstream commit 2d1b5c08366acd46c35a2e9aba5d650cb5bf5c19 ]

The virmidi driver has an open race at closing its assigned rawmidi
device, and this may lead to use-after-free in

Plug the hole by properly protecting the linked list deletion and
calling in the right order in snd_virmidi_input_close().

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agocrypto: algif_hash - wait for crypto_ahash_init() to complete
Wang, Rui Y [Wed, 27 Jan 2016 09:08:37 +0000 (17:08 +0800)]
crypto: algif_hash - wait for crypto_ahash_init() to complete

[ Upstream commit fe09786178f9df713a4b2dd6b93c0a722346bf5e ]

hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.

Signed-off-by: Rui Wang <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000
Lev Lybin [Fri, 29 Jan 2016 15:55:11 +0000 (22:55 +0700)]
ALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000

[ Upstream commit 1b3c993a699bed282e47c3f7c49d539c331dae04 ]

Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for
avoiding the stall due to the invalid sample rate reads.

Signed-off-by: Lev Lybin <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC
Jurgen Kramer [Fri, 29 Jan 2016 13:59:25 +0000 (14:59 +0100)]
ALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC

[ Upstream commit ad678b4ccd41aa51cf5f142c0e8cffe9d61fc2bf ]

This patch adds native DSD support for the PS Audio NuWave DAC.

Signed-off-by: Jurgen Kramer <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: usb: Add native DSD support for Aune X1S
Jurgen Kramer [Mon, 9 Nov 2015 11:13:55 +0000 (12:13 +0100)]
ALSA: usb: Add native DSD support for Aune X1S

[ Upstream commit 3577eb6d02c3f5bf751f60f125e34c2197605c65 ]

commit 16771c7c704769c5f3d70c024630b6e5b3eafa67 upstream.

This patch adds native DSD support for the Aune X1S 32BIT/384 DSD DAC

Signed-off-by: Jurgen Kramer <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agodrm/i915/dp: fall back to 18 bpp when sink capability is unknown
Jani Nikula [Wed, 13 Jan 2016 14:35:20 +0000 (16:35 +0200)]
drm/i915/dp: fall back to 18 bpp when sink capability is unknown

[ Upstream commit 5efd407674068dede403551bea3b0b134c32513a ]

Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic

The clamping has been HDMI specific since its introduction in

commit 996a2239f93b03c5972923f04b097f65565c5bed
Author: Daniel Vetter <>
Date:   Fri Apr 19 11:24:34 2013 +0200

    drm/i915: Disable high-bpc on pre-1.4 EDID screens

Reported-and-tested-by: Dihan Wickremasuriya <>
Reviewed-by: Ville Syrjälä <>
Signed-off-by: Jani Nikula <>
(cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
Signed-off-by: Sasha Levin <>
4 years agocrypto: shash - Fix has_key setting
Herbert Xu [Tue, 26 Jan 2016 16:16:37 +0000 (00:16 +0800)]
crypto: shash - Fix has_key setting

[ Upstream commit 00420a65fa2beb3206090ead86942484df2275f3 ]

The has_key logic is wrong for shash algorithms as they always
have a setkey function.  So we should instead be testing against

Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey")
Reported-by: Stephan Mueller <>
Signed-off-by: Herbert Xu <>
Tested-by: Stephan Mueller <>
Signed-off-by: Sasha Levin <>
4 years agoARM: dts: at91: sama5d4: fix instance id of DBGU
Mohamed Jamsheeth Hajanajubudeen [Fri, 11 Dec 2015 11:36:26 +0000 (17:06 +0530)]
ARM: dts: at91: sama5d4: fix instance id of DBGU

[ Upstream commit 929e883f2bfdf68d4bd3aec43912e956417005c7 ]

Change instance id of DBGU to 45.

Signed-off-by: Mohamed Jamsheeth Hajanajubudeen <>
Fixes: 7c661394c56c ("ARM: at91: dt: add device tree file for SAMA5D4 SoC")
Cc: # 3.18+
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Sasha Levin <>
4 years agorfkill: fix rfkill_fop_read wait_event usage
Johannes Berg [Tue, 26 Jan 2016 10:29:03 +0000 (11:29 +0100)]
rfkill: fix rfkill_fop_read wait_event usage

[ Upstream commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 ]

The code within wait_event_interruptible() is called with
!TASK_RUNNING, so mustn't call any functions that can sleep,
like mutex_lock().

Since we re-check the list_empty() in a loop after the wait,
it's safe to simply use list_empty() without locking.

This bug has existed forever, but was only discovered now
because all userspace implementations, including the default
'rfkill' tool, use poll() or select() to get a readable fd
before attempting to read.

Fixes: c64fb01627e24 ("rfkill: create useful userspace interface")
Reported-by: Dmitry Vyukov <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Sasha Levin <>
4 years agomac80211: Requeue work after scan complete for all VIF types.
Sachin Kulkarni [Tue, 12 Jan 2016 09:00:19 +0000 (14:30 +0530)]
mac80211: Requeue work after scan complete for all VIF types.

[ Upstream commit 4fa11ec726a32ea6dd768dbb2e2af3453a98ec0a ]

During a sw scan ieee80211_iface_work ignores work items for all vifs.
However after the scan complete work is requeued only for STA, ADHOC
and MESH iftypes.

This occasionally results in event processing getting delayed/not
processed for iftype AP when it coexists with a STA. This can result
in data halt and eventually disconnection on the AP interface.

Signed-off-by: Sachin Kulkarni <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Sasha Levin <>
4 years agoarm64: restore bogomips information in /proc/cpuinfo
Yang Shi [Wed, 18 Nov 2015 18:48:55 +0000 (10:48 -0800)]
arm64: restore bogomips information in /proc/cpuinfo

[ Upstream commit 92e788b749862ebe9920360513a718e5dd4da7a9 ]

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi <>
Acked-by: Will Deacon <>
Cc: <> # 3.12+
Signed-off-by: Catalin Marinas <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: fix invalid memory access in hub_activate()
Alan Stern [Wed, 16 Dec 2015 18:32:38 +0000 (13:32 -0500)]
USB: fix invalid memory access in hub_activate()

[ Upstream commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea ]

Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be

Signed-off-by: Alan Stern <>
Reported-by: Alexandru Cornea <>
Tested-by: Alexandru Cornea <>
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
CC: <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agoserial: 8250_pci: Add Intel Broadwell ports
Mika Westerberg [Fri, 29 Jan 2016 14:49:47 +0000 (16:49 +0200)]
serial: 8250_pci: Add Intel Broadwell ports

[ Upstream commit 6c55d9b98335f7f6bd5f061866ff1633401f3a44 ]

Some recent (early 2015) macbooks have Intel Broadwell where LPSS UARTs are
PCI enumerated instead of ACPI. The LPSS UART block is pretty much same as
used on Intel Baytrail so we can reuse the existing Baytrail setup code.

Add both Broadwell LPSS UART ports to the list of supported devices.

Signed-off-by: Leif Liddy <>
Signed-off-by: Mika Westerberg <>
Reviewed-by: Andy Shevchenko <>
Reviewed-by: Heikki Krogerus <>
Cc: stable <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agox86/mm/pat: Avoid truncation when converting cpa->numpages to address
Matt Fleming [Fri, 29 Jan 2016 11:36:10 +0000 (11:36 +0000)]
x86/mm/pat: Avoid truncation when converting cpa->numpages to address

[ Upstream commit 742563777e8da62197d6cb4b99f4027f59454735 ]

There are a couple of nasty truncation bugs lurking in the pageattr
code that can be triggered when mapping EFI regions, e.g. when we pass
a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting
left by PAGE_SHIFT will truncate the resultant address to 32-bits.

Viorel-Cătălin managed to trigger this bug on his Dell machine that
provides a ~5GB EFI region which requires 1236992 pages to be mapped.
When calling populate_pud() the end of the region gets calculated
incorrectly in the following buggy expression,

  end = start + (cpa->numpages << PAGE_SHIFT);

And only 188416 pages are mapped. Next, populate_pud() gets invoked
for a second time because of the loop in __change_page_attr_set_clr(),
only this time no pages get mapped because shifting the remaining
number of pages (1048576) by PAGE_SHIFT is zero. At which point the
loop in __change_page_attr_set_clr() spins forever because we fail to
map progress.

Hitting this bug depends very much on the virtual address we pick to
map the large region at and how many pages we map on the initial run
through the loop. This explains why this issue was only recently hit
with the introduction of commit

  a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap
   entries bottom-up at runtime, instead of top-down")

It's interesting to note that safe uses of cpa->numpages do exist in
the pageattr code. If instead of shifting ->numpages we multiply by
PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and
so the result is unsigned long.

To avoid surprises when users try to convert very large cpa->numpages
values to addresses, change the data type from 'int' to 'unsigned
long', thereby making it suitable for shifting by PAGE_SHIFT without
any type casting.

The alternative would be to make liberal use of casting, but that is
far more likely to cause problems in the future when someone adds more
code and fails to cast properly; this bug was difficult enough to
track down in the first place.

Reported-and-tested-by: Viorel-Cătălin Răpițeanu <>
Acked-by: Borislav Petkov <>
Cc: Sai Praneeth Prakhya <>
Cc: <>
Signed-off-by: Matt Fleming <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Sasha Levin <>
4 years agoStaging: speakup: Fix getting port information
Samuel Thibault [Thu, 14 Jan 2016 23:47:41 +0000 (00:47 +0100)]
Staging: speakup: Fix getting port information

[ Upstream commit 327b882d3bcc1fba82dbd39b5cf5a838c81218e2 ]

Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h>
instead of <asm/serial.h>") broke the port information in the speakup
driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
and no other header includes asm/serial.h.

We here make sure serialio.c does get the arch-specific definition of
SERIAL_PORT_DFNS from asm/serial.h, if any.

Along the way, this makes sure that we do have information for the
requested serial port number (index)

Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")
Signed-off-by: Samuel Thibault <>
Cc: stable <> # 3.18
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agodrm/vmwgfx: respect 'nomodeset'
Rob Clark [Wed, 15 Oct 2014 19:00:47 +0000 (15:00 -0400)]
drm/vmwgfx: respect 'nomodeset'

[ Upstream commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 ]

Signed-off-by: Rob Clark <>
Reviewed-by: Thomas Hellstrom <>.
Signed-off-by: Dave Airlie <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: dummy: Disable switching timer backend via sysfs
Takashi Iwai [Thu, 28 Jan 2016 06:54:16 +0000 (07:54 +0100)]
ALSA: dummy: Disable switching timer backend via sysfs

[ Upstream commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 ]

ALSA dummy driver can switch the timer backend between system timer
and hrtimer via its hrtimer module option.  This can be also switched
dynamically via sysfs, but it may lead to a memory corruption when
switching is done while a PCM stream is running; the stream instance
for the newly switched timer method tries to access the memory that
was allocated by another timer method although the sizes differ.

As the simplest fix, this patch just disables the switch via sysfs by
dropping the writable bit.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoseccomp: always propagate NO_NEW_PRIVS on tsync
Jann Horn [Sat, 26 Dec 2015 05:00:48 +0000 (06:00 +0100)]
seccomp: always propagate NO_NEW_PRIVS on tsync

[ Upstream commit 103502a35cfce0710909da874f092cb44823ca03 ]

Before this patch, a process with some permissive seccomp filter
that was applied by root without NO_NEW_PRIVS was able to add
more filters to itself without setting NO_NEW_PRIVS by setting
the new filter from a throwaway thread with NO_NEW_PRIVS.

Signed-off-by: Jann Horn <>
Signed-off-by: Kees Cook <>
Signed-off-by: Sasha Levin <>
4 years agoirqchip/atmel-aic: Fix wrong bit operation for IRQ priority
Milo Kim [Wed, 13 Jan 2016 07:19:50 +0000 (16:19 +0900)]
irqchip/atmel-aic: Fix wrong bit operation for IRQ priority

[ Upstream commit 49f34134aea74f19ca016f055d25ee55ec359dee ]

Atmel AIC has common structure for SMR (Source Mode Register).

  bit[6:5] Interrupt source type
  bit[2:0] Priority level
  Other bits are unused.

To update new priority value, bit[2:0] should be cleared first and then
new priority level can be written. However, aic_common_set_priority()
helper clears source type bits instead of priority bits.
This patch fixes wrong mask bit operation.

Fixes: b1479ebb7720 "irqchip: atmel-aic: Add atmel AIC/AIC5 drivers"
Signed-off-by: Milo Kim <>
Acked-by: Boris Brezillon <>
Cc: Jason Cooper <>
Cc: Marc Zyngier <>
Cc: Ludovic Desroches <>
Cc: Nicholas Ferre <>
Cc: #v3.17+
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Sasha Levin <>
4 years agostaging/speakup: Use tty_ldisc_ref() for paste kworker
Peter Hurley [Mon, 11 Jan 2016 06:40:58 +0000 (22:40 -0800)]
staging/speakup: Use tty_ldisc_ref() for paste kworker

[ Upstream commit f4f9edcf9b5289ed96113e79fa65a7bf27ecb096 ]

As the function documentation for tty_ldisc_ref_wait() notes, it is
only callable from a tty file_operations routine; otherwise there
is no guarantee the ref won't be NULL.

The key difference with the VT's paste_selection() is that is an ioctl,
where __speakup_paste_selection() is completely async kworker, kicked
off from interrupt context.

Fixes: 28a821c30688 ("Staging: speakup: Update __speakup_paste_selection()
       tty (ab)usage to match vt")
Cc: <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agon_tty: Fix unsafe reference to "other" ldisc
Peter Hurley [Mon, 11 Jan 2016 06:40:56 +0000 (22:40 -0800)]
n_tty: Fix unsafe reference to "other" ldisc

[ Upstream commit 6d27a63caad3f13e96cf065d2d96828c2006be6b ]

Although n_tty_check_unthrottle() has a valid ldisc reference (since
the tty core gets the ldisc ref in tty_read() before calling the line
discipline read() method), it does not have a valid ldisc reference to
the "other" pty of a pty pair. Since getting an ldisc reference for
tty->link essentially open-codes tty_wakeup(), just replace with the
equivalent tty_wakeup().

Cc: <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agotty: Fix unsafe ldisc reference via ioctl(TIOCGETD)
Peter Hurley [Mon, 11 Jan 2016 06:40:55 +0000 (22:40 -0800)]
tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

[ Upstream commit 5c17c861a357e9458001f021a7afa7aab9937439 ]

ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).

However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.

Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.

Cc: <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agoSCSI: fix crashes in sd and sr runtime PM
Alan Stern [Wed, 20 Jan 2016 16:26:01 +0000 (11:26 -0500)]
SCSI: fix crashes in sd and sr runtime PM

[ Upstream commit 13b4389143413a1f18127c07f72c74cad5b563e8 ]

Runtime suspend during driver probe and removal can cause problems.
The driver's runtime_suspend or runtime_resume callbacks may invoked
before the driver has finished binding to the device or after the
driver has unbound from the device.

This problem shows up with the sd and sr drivers, and can cause disk
or CD/DVD drives to become unusable as a result.  The fix is simple.
The drivers store a pointer to the scsi_disk or scsi_cd structure as
their private device data when probing is finished, so we simply have
to be sure to clear the private data during removal and test it during
runtime suspend/resume.

This fixes <>.

Signed-off-by: Alan Stern <>
Reported-by: Paul Menzel <>
Reported-by: Erich Schubert <>
Reported-by: Alexandre Rossi <>
Tested-by: Paul Menzel <>
Tested-by: Erich Schubert <>
CC: <>
Signed-off-by: James Bottomley <>
Signed-off-by: Sasha Levin <>
4 years agopowerpc/eeh: Fix PE location code
Gavin Shan [Wed, 2 Dec 2015 05:25:32 +0000 (16:25 +1100)]
powerpc/eeh: Fix PE location code

[ Upstream commit 7e56f627768da4e6480986b5145dc3422bc448a5 ]

In eeh_pe_loc_get(), the PE location code is retrieved from the
"ibm,loc-code" property of the device node for the bridge of the
PE's primary bus. It's not correct because the property indicates
the parent PE's location code.

This reads the correct PE location code from "ibm,io-base-loc-code"
or "ibm,slot-location-code" property of PE parent bus's device node.

Cc: # v3.16+
Fixes: 357b2f3dd9b7 ("powerpc/eeh: Dump PE location code")
Signed-off-by: Gavin Shan <>
Tested-by: Russell Currey <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Sasha Levin <>
4 years agoarm64: mm: avoid calling apply_to_page_range on empty range
Mika Penttilä [Tue, 26 Jan 2016 15:47:25 +0000 (15:47 +0000)]
arm64: mm: avoid calling apply_to_page_range on empty range

[ Upstream commit 57adec866c0440976c96a4b8f5b59fb411b1cacb ]

Calling apply_to_page_range with an empty range results in a BUG_ON
from the core code. This can be triggered by trying to load the st_drv
module with CONFIG_DEBUG_SET_MODULE_RONX enabled:

  kernel BUG at mm/memory.c:1874!
  Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2
  Hardware name: ARM Juno development board (r0) (DT)
  task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000
  PC is at apply_to_page_range+0x2cc/0x2d0
  LR is at change_memory_common+0x80/0x108

This patch fixes the issue by making change_memory_common (called by the
set_memory_* functions) a NOP when numpages == 0, therefore avoiding the
erroneous call to apply_to_page_range and bringing us into line with x86
and s390.

Cc: <>
Reviewed-by: Laura Abbott <>
Acked-by: David Rientjes <>
Signed-off-by: Mika Penttilä <>
Signed-off-by: Will Deacon <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: bebob: Use a signed return type for get_formation_index
Lucas Tanure [Mon, 25 Jan 2016 21:30:23 +0000 (19:30 -0200)]
ALSA: bebob: Use a signed return type for get_formation_index

[ Upstream commit 07905298e4d5777eb58516cdc242f7ac1ca387a2 ]

The return type "unsigned int" was used by the get_formation_index function
despite of the aspect that it will eventually return a negative error code.
So, change to signed int and get index by reference in the parameters.

Done with the help of Coccinelle.

[Fix the missing braces suggested by Julia Lawall -- tiwai]

Signed-off-by: Lucas Tanure <>
Reviewed-by: Takashi Sakamoto <>
Tested-by: Takashi Sakamoto <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay
Guillaume Fougnies [Mon, 25 Jan 2016 23:28:27 +0000 (00:28 +0100)]
ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay

[ Upstream commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a ]

TEAC UD-501/UD-503/NT-503 fail to switch properly between different
rate/format. Similar to 'Playback Design', this patch corrects the
invalid clock source error for TEAC products and avoids complete
freeze of the usb interface of 503 series.

Signed-off-by: Guillaume Fougnies <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures
Takashi Iwai [Mon, 25 Jan 2016 12:59:21 +0000 (13:59 +0100)]
ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures

[ Upstream commit 462b3f161beb62eeb290f4ec52f5ead29a2f8ac7 ]

Some architectures like PowerPC can handle the maximum struct size in
an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit.  This
problem was revealed recently by a powerpc change, as it's now treated
as a fatal build error.

This patch is a stop-gap for that: for architectures with less than 14
bit ioctl struct size, get rid of the handling of the relevant ioctl.
We should provide an alternative equivalent ioctl code later, but for
now just paper over it.  Luckily, the compress API hasn't been used on
such architectures, so the impact must be effectively zero.

Reviewed-by: Mark Brown <>
Acked-by: Sudip Mukherjee <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: option: fix Cinterion AHxx enumeration
John Ernberg [Mon, 25 Jan 2016 12:27:17 +0000 (12:27 +0000)]
USB: option: fix Cinterion AHxx enumeration

[ Upstream commit 4152b387da81617c80cb2946b2d56e3958906b3e ]

In certain kernel configurations where the cdc_ether and option drivers
are compiled as modules there can occur a race condition in enumeration.
This causes the option driver to enumerate the ethernet(wwan) interface
as usb-serial interfaces.

usb-devices output for the modem:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1e2d ProdID=0055 Rev=00.00
S:  Manufacturer=Cinterion
S:  Product=AHx
C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether

Signed-off-by: John Ernberg <>
Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...")
Cc: stable <> # v3.9: 8ff10bdb14a52
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: serial: ftdi_sio: add support for Yaesu SCU-18 cable
Greg Kroah-Hartman [Wed, 20 Jan 2016 07:43:13 +0000 (23:43 -0800)]
USB: serial: ftdi_sio: add support for Yaesu SCU-18 cable

[ Upstream commit e03cdf22a2727c60307be6a729233edab3bfda9c ]

Harald Linden reports that the ftdi_sio driver works properly for the
Yaesu SCU-18 cable if the device ids are added to the driver.  So let's
add them.

Reported-by: Harald Linden <>
Cc: stable <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: seq: Degrade the error message for too many opens
Takashi Iwai [Mon, 25 Jan 2016 10:24:56 +0000 (11:24 +0100)]
ALSA: seq: Degrade the error message for too many opens

[ Upstream commit da10816e3d923565b470fec78a674baba794ed33 ]

ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too
many applications") when user-space tries to open more than the
limit.  This means that it can easily fill the log buffer.

Since it's merely a normal error, it's safe to suppress it via
pr_debug() instead.

Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup()
Takashi Iwai [Mon, 25 Jan 2016 10:01:47 +0000 (11:01 +0100)]
ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup()

[ Upstream commit 599151336638d57b98d92338aa59c048e3a3e97d ]

ALSA sequencer OSS emulation code has a sanity check for currently
opened devices, but there is a thinko there, eventually it spews
warnings and skips the operation wrongly like:
  WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311

Fix this off-by-one error.

Reported-by: Dmitry Vyukov <>
Cc: <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: serial: option: Adding support for Telit LE922
Daniele Palmas [Tue, 12 Jan 2016 16:22:06 +0000 (17:22 +0100)]
USB: serial: option: Adding support for Telit LE922

[ Upstream commit ff4e2494dc17b173468e1713fdf6237fd8578bc7 ]

This patch adds support for two PIDs of LE922.

Signed-off-by: Daniele Palmas <>
Cc: stable <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: serial: visor: fix crash on detecting device without write_urbs
Vladis Dronov [Tue, 12 Jan 2016 14:10:50 +0000 (15:10 +0100)]
USB: serial: visor: fix crash on detecting device without write_urbs

[ Upstream commit cb3232138e37129e88240a98a1d2aba2187ff57c ]

The visor driver crashes in clie_5_attach() when a specially crafted USB
device without bulk-out endpoint is detected. This fix adds a check that
the device has proper configuration expected by the driver.

Reported-by: Ralf Spenneberg <>
Signed-off-by: Vladis Dronov <>
Fixes: cfb8da8f69b8 ("USB: visor: fix initialisation of UX50/TH55 devices")
Cc: stable <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: visor: fix null-deref at probe
Johan Hovold [Tue, 12 Jan 2016 11:05:20 +0000 (12:05 +0100)]
USB: visor: fix null-deref at probe

[ Upstream commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 ]

Fix null-pointer dereference at probe should a (malicious) Treo device
lack the expected endpoints.

Specifically, the Treo port-setup hack was dereferencing the bulk-in and
interrupt-in urbs without first making sure they had been allocated by

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agoUSB: cp210x: add ID for IAI USB to RS485 adaptor
Peter Dedecker [Fri, 8 Jan 2016 11:34:41 +0000 (12:34 +0100)]
USB: cp210x: add ID for IAI USB to RS485 adaptor

[ Upstream commit f487c54ddd544e1c9172cd510954f697b77b76e3 ]

Added the USB serial console device ID for IAI Corp. RCB-CV-USB
USB to RS485 adaptor.

Signed-off-by: Peter Dedecker <>
Cc: stable <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Sasha Levin <>
4 years agousb: hub: do not clear BOS field during reset device
Du, Changbin [Mon, 18 Jan 2016 13:02:42 +0000 (21:02 +0800)]
usb: hub: do not clear BOS field during reset device

[ Upstream commit d8f00cd685f5c8e0def8593e520a7fef12c22407 ]

In function usb_reset_and_verify_device, the old BOS descriptor may
still be used before allocating a new one. (usb_unlocked_disable_lpm
function uses it under the situation that it fails to disable lpm.)
So we cannot set the udev->bos to NULL before that, just keep what it
was. It will be overwrite when allocating a new one.

Crash log:
BUG: unable to handle kernel NULL pointer dereference at
IP: [<ffffffff8171f98d>] usb_enable_link_state+0x2d/0x2f0
Call Trace:
[<ffffffff8171ed5b>] ? usb_set_lpm_timeout+0x12b/0x140
[<ffffffff8171fcd1>] usb_enable_lpm+0x81/0xa0
[<ffffffff8171fdd8>] usb_disable_lpm+0xa8/0xc0
[<ffffffff8171fe1c>] usb_unlocked_disable_lpm+0x2c/0x50
[<ffffffff81723933>] usb_reset_and_verify_device+0xc3/0x710
[<ffffffff8172c4ed>] ? usb_sg_wait+0x13d/0x190
[<ffffffff81724743>] usb_reset_device+0x133/0x280
[<ffffffff8179ccd1>] usb_stor_port_reset+0x61/0x70
[<ffffffff8179cd68>] usb_stor_invoke_transport+0x88/0x520

Signed-off-by: Du, Changbin <>
Cc: stable <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agocdc-acm:exclude Samsung phone 04e8:685d
Oliver Neukum [Mon, 18 Jan 2016 14:45:18 +0000 (15:45 +0100)]
cdc-acm:exclude Samsung phone 04e8:685d

[ Upstream commit e912e685f372ab62a2405a1acd923597f524e94a ]

This phone needs to be handled by a specialised firmware tool
and is reported to crash irrevocably if cdc-acm takes it.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>
4 years agousb: cdc-acm: send zero packet for intel 7260 modem
Lu Baolu [Wed, 6 Jan 2016 07:10:04 +0000 (15:10 +0800)]
usb: cdc-acm: send zero packet for intel 7260 modem

[ Upstream commit ffdb1e369a73b380fce95b05f8498d92c43842b4 ]

For Intel 7260 modem, it is needed for host side to send zero
packet if the BULK OUT size is equal to USB endpoint max packet
length. Otherwise, modem side may still wait for more data and
cannot give response to host side.

Signed-off-by: Konrad Leszczynski <>
Signed-off-by: Lu Baolu <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Sasha Levin <>