7 years agosctp: Fix port hash table size computation
Neil Horman [Thu, 18 Feb 2016 21:10:57 +0000 (16:10 -0500)]
sctp: Fix port hash table size computation

[ Upstream commit d9749fb5942f51555dc9ce1ac0dbb1806960a975 ]

Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
its size computation, observing that the current method never guaranteed
that the hashsize (measured in number of entries) would be a power of two,
which the input hash function for that table requires.  The root cause of
the problem is that two values need to be computed (one, the allocation
order of the storage requries, as passed to __get_free_pages, and two the
number of entries for the hash table).  Both need to be ^2, but for
different reasons, and the existing code is simply computing one order
value, and using it as the basis for both, which is wrong (i.e. it assumes
that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).

To fix this, we change the logic slightly.  We start by computing a goal
allocation order (which is limited by the maximum size hash table we want
to support.  Then we attempt to allocate that size table, decreasing the
order until a successful allocation is made.  Then, with the resultant
successful order we compute the number of buckets that hash table supports,
which we then round down to the nearest power of two, giving us the number
of entries the table actually supports.

I've tested this locally here, using non-debug and spinlock-debug kernels,
and the number of entries in the hashtable consistently work out to be
powers of two in all cases.

Signed-off-by: Neil Horman <>
Reported-by: Dmitry Vyukov <>
CC: Dmitry Vyukov <>
CC: Vladislav Yasevich <>
CC: "David S. Miller" <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agopppoe: fix reference counting in PPPoE proxy
Guillaume Nault [Mon, 15 Feb 2016 16:01:10 +0000 (17:01 +0100)]
pppoe: fix reference counting in PPPoE proxy

[ Upstream commit 29e73269aa4d36f92b35610c25f8b01c789b0dc8 ]

Drop reference on the relay_po socket when __pppoe_xmit() succeeds.
This is already handled correctly in the error path.

Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoipv4: fix memory leaks in ip_cmsg_send() callers
Eric Dumazet [Thu, 4 Feb 2016 14:23:28 +0000 (06:23 -0800)]
ipv4: fix memory leaks in ip_cmsg_send() callers

[ Upstream commit 919483096bfe75dda338e98d56da91a263746a0a ]

Dmitry reported memory leaks of IP options allocated in
ip_cmsg_send() when/if this function returns an error.

Callers are responsible for the freeing.

Many thanks to Dmitry for the report and diagnostic.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agonet/ipv6: add sysctl option accept_ra_min_hop_limit
Hangbin Liu [Thu, 30 Jul 2015 06:28:42 +0000 (14:28 +0800)]
net/ipv6: add sysctl option accept_ra_min_hop_limit

[ Upstream commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 ]

Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
disabled accept hop limit from RA if it is smaller than the current hop
limit for security stuff. But this behavior kind of break the RFC definition.

RFC 4861, 6.3.4.  Processing Received Router Advertisements
   A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
   and Retrans Timer) may contain a value denoting that it is
   unspecified.  In such cases, the parameter should be ignored and the
   host should continue using whatever value it is already using.

   If the received Cur Hop Limit value is non-zero, the host SHOULD set
   its CurHopLimit variable to the received value.

So add sysctl option accept_ra_min_hop_limit to let user choose the minimum
hop limit value they can accept from RA. And set default to 1 to meet RFC

Signed-off-by: Hangbin Liu <>
Acked-by: YOSHIFUJI Hideaki <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Number DEVCONF enumerators explicitly to match upstream]
Signed-off-by: Ben Hutchings <>
7 years agoipv6/udp: use sticky pktinfo egress ifindex on connect()
Paolo Abeni [Fri, 29 Jan 2016 11:30:20 +0000 (12:30 +0100)]
ipv6/udp: use sticky pktinfo egress ifindex on connect()

[ Upstream commit 1cdda91871470f15e79375991bd2eddc6e86ddb1 ]

Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space application calls connect()
before sendmsg().
Fix it by initializing properly flowi6_oif in connect() before
performing the route lookup.

Signed-off-by: Paolo Abeni <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: dp83640: Fix tx timestamp overflow handling.
Manfred Rudigier [Wed, 20 Jan 2016 10:22:28 +0000 (11:22 +0100)]
net: dp83640: Fix tx timestamp overflow handling.

[ Upstream commit 81e8f2e930fe76b9814c71b9d87c30760b5eb705 ]

PHY status frames are not reliable, the PHY may not be able to send them
during heavy receive traffic. This overflow condition is signaled by the
PHY in the next status frame, but the driver did not make use of it.
Instead it always reported wrong tx timestamps to user space after an
overflow happened because it assigned newly received tx timestamps to old
packets in the queue.

This commit fixes this issue by clearing the tx timestamp queue every time
an overflow happens, so that no timestamps are delivered for overflow
packets. This way time stamping will continue correctly after an overflow.

Signed-off-by: Manfred Rudigier <>
Acked-by: Richard Cochran <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoaf_iucv: Validate socket address length in iucv_sock_bind()
Ursula Braun [Tue, 19 Jan 2016 09:41:33 +0000 (10:41 +0100)]
af_iucv: Validate socket address length in iucv_sock_bind()

[ Upstream commit 52a82e23b9f2a9e1d429c5207f8575784290d008 ]

Signed-off-by: Ursula Braun <>
Reported-by: Dmitry Vyukov <>
Reviewed-by: Evgeny Cherkashin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 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 <>
[bwh: Backported to 3.2:
 - Adjust context
 - Add skb argument to other callers of IP6_ECN_set_ce()]
Signed-off-by: Ben Hutchings <>
7 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: Ben Hutchings <>
7 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: Ben Hutchings <>
7 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 <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 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 <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 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 <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoext4: fix NULL pointer dereference in ext4_mark_inode_dirty()
Eryu Guan [Sun, 13 Mar 2016 02:40:32 +0000 (21:40 -0500)]
ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()

commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 upstream.

ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on
error (e.g. EIO) and can be NULL in this case. But the error is
ignored in the following "if" condition and ext4_expand_extra_isize()
might be called with NULL set, which triggers NULL pointer

This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for
the project quota feature"), which enlarges the ext4_inode size, and
run the following script on new kernel but with old mke2fs:


  trap cleanup 0 1 2 3 9 15

          umount $mnt >/dev/null 2>&1
          dmsetup remove $devname
          losetup -d $backend_dev
          rm -f $fsimg
          exit 0

  rm -f $fsimg
  fallocate -l 1g $fsimg
  backend_dev=`losetup -f --show $fsimg`
  devsize=`blockdev --getsz $backend_dev`

  good_tab="0 $devsize linear $backend_dev 0"
  error_tab="0 $devsize error $backend_dev 0"

  dmsetup create $devname --table "$good_tab"

  mkfs -t ext4 $dev
  mount -t ext4 -o errors=continue,strictatime $dev $mnt

  dmsetup load $devname --table "$error_tab" && dmsetup resume $devname
  echo 3 > /proc/sys/vm/drop_caches
  ls -l $mnt
  exit 0

[ Patch changed to simplify the function a tiny bit. -- Ted ]

Signed-off-by: Eryu Guan <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
7 years agoipv4: Don't do expensive useless work during inetdev destroy.
David S. Miller [Mon, 14 Mar 2016 03:28:00 +0000 (23:28 -0400)]
ipv4: Don't do expensive useless work during inetdev destroy.

commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 upstream.

When an inetdev is destroyed, every address assigned to the interface
is removed.  And in this scenerio we do two pointless things which can
be very expensive if the number of assigned interfaces is large:

1) Address promotion.  We are deleting all addresses, so there is no
   point in doing this.

2) A full nf conntrack table purge for every address.  We only need to
   do this once, as is already caught by the existing
   masq_dev_notifier so masq_inet_event() can skip this.

Reported-by: Solar Designer <>
Signed-off-by: David S. Miller <>
Tested-by: Cyrill Gorcunov <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usbip: fix potential out-of-bounds write
Ignat Korchagin [Thu, 17 Mar 2016 18:00:29 +0000 (18:00 +0000)]
USB: usbip: fix potential out-of-bounds write

commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream.

Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.

Signed-off-by: Ignat Korchagin <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agousbnet: cleanup after bind() in probe()
Oliver Neukum [Mon, 7 Mar 2016 10:31:10 +0000 (11:31 +0100)]
usbnet: cleanup after bind() in probe()

commit 1666984c8625b3db19a9abc298931d35ab7bc64b upstream.

In case bind() works, but a later error forces bailing
in probe() in error cases work and a timer may be scheduled.
They must be killed. This fixes an error case related to
the double free reported in
and needs to go on top of Linus' fix to cdc-ncm.

Signed-off-by: Oliver Neukum <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agox86/mm/32: Enable full randomization on i386 and X86_32
Hector Marco-Gisbert [Thu, 10 Mar 2016 19:51:00 +0000 (20:51 +0100)]
x86/mm/32: Enable full randomization on i386 and X86_32

commit 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb upstream.

Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
the stack and the executable are randomized but not other mmapped files
(libraries, vDSO, etc.). This patch enables randomization for the
libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.

By default on i386 there are 8 bits for the randomization of the libraries,
vDSO and mmaps which only uses 1MB of VA.

This patch preserves the original randomness, using 1MB of VA out of 3GB or
4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.

The first obvious security benefit is that all objects are randomized (not
only the stack and the executable) in legacy mode which highly increases
the ASLR effectiveness, otherwise the attackers may use these
non-randomized areas. But also sensitive setuid/setgid applications are
more secure because currently, attackers can disable the randomization of
these applications by setting the ulimit stack to "unlimited". This is a
very old and widely known trick to disable the ASLR in i386 which has been
allowed for too long.

Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
personality flag, but fortunately this doesn't work on setuid/setgid
applications because there is security checks which clear Security-relevant

This patch always randomizes the mmap_legacy_base address, removing the
possibility to disable the ASLR by setting the stack to "unlimited".

Signed-off-by: Hector Marco-Gisbert <>
Acked-by: Ismael Ripoll Ripoll <>
Acked-by: Kees Cook <>
Acked-by: Arjan van de Ven <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: kees Cook <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agox86: standardize mmap_rnd() usage
Kees Cook [Tue, 14 Apr 2015 22:47:45 +0000 (15:47 -0700)]
x86: standardize mmap_rnd() usage

commit 82168140bc4cec7ec9bad39705518541149ff8b7 upstream.

In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm, and extracts the checking of

Signed-off-by: Kees Cook <>
Reviewed-by: Ingo Molnar <>
Cc: Oleg Nesterov <>
Cc: Andy Lutomirski <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agonetfilter: x_tables: make sure e->next_offset covers remaining blob size
Florian Westphal [Tue, 22 Mar 2016 17:02:50 +0000 (18:02 +0100)]
netfilter: x_tables: make sure e->next_offset covers remaining blob size

commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream.

Otherwise this function may read data beyond the ruleset blob.

Signed-off-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
7 years agonetfilter: x_tables: validate e->target_offset early
Florian Westphal [Tue, 22 Mar 2016 17:02:49 +0000 (18:02 +0100)]
netfilter: x_tables: validate e->target_offset early

commit bdf533de6968e9686df777dc178486f600c6e617 upstream.

We should check that e->target_offset is sane before
mark_source_chains gets called since it will fetch the target entry
for loop detection.

Signed-off-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoparisc: Unbreak handling exceptions from kernel modules
Helge Deller [Fri, 8 Apr 2016 16:32:52 +0000 (18:32 +0200)]
parisc: Unbreak handling exceptions from kernel modules

commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 upstream.

Handling exceptions from modules never worked on parisc.
It was just masked by the fact that exceptions from modules
don't happen during normal use.

When a module triggers an exception in get_user() we need to load the
main kernel dp value before accessing the exception_data structure, and
afterwards restore the original dp value of the module on exit.

Noticed-by: Mikulas Patocka <>
Signed-off-by: Helge Deller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoparisc: Fix kernel crash with reversed copy_from_user()
Helge Deller [Fri, 8 Apr 2016 16:18:48 +0000 (18:18 +0200)]
parisc: Fix kernel crash with reversed copy_from_user()

commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 upstream.

The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
crash on parisc if the parameters for copy_from_user were reversed
("illegal reversed copy_to_user" testcase).

Fix this potential crash by checking the fault handler if the faulting
address is in the exception table.

Signed-off-by: Helge Deller <>
Cc: Kees Cook <>
Signed-off-by: Ben Hutchings <>
7 years agoparisc: Avoid function pointers for kernel exception routines
Helge Deller [Fri, 8 Apr 2016 16:11:33 +0000 (18:11 +0200)]
parisc: Avoid function pointers for kernel exception routines

commit e3893027a300927049efc1572f852201eb785142 upstream.

We want to avoid the kernel module loader to create function pointers
for the kernel fixup routines of get_user() and put_user(). Changing
the external reference from function type to int type fixes this.

This unbreaks exception handling for get_user() and put_user() when
called from a kernel module.

Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: serial: cp210x: Adding GE Healthcare Device ID
Martyn Welch [Tue, 29 Mar 2016 16:47:29 +0000 (17:47 +0100)]
USB: serial: cp210x: Adding GE Healthcare Device ID

commit cddc9434e3dcc37a85c4412fb8e277d3a582e456 upstream.

The CP2105 is used in the GE Healthcare Remote Alarm Box, with the
Manufacturer ID of 0x1901 and Product ID of 0x0194.

Signed-off-by: Martyn Welch <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices
Josh Boyer [Thu, 10 Mar 2016 14:48:52 +0000 (09:48 -0500)]
USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices

commit ea6db90e750328068837bed34cb1302b7a177339 upstream.

A Fedora user reports that the ftdi_sio driver works properly for the
ICP DAS I-7561U device.  Further, the user manual for these devices
instructs users to load the driver and add the ids using the sysfs

Add support for these in the driver directly so that the devices work
out of the box instead of needing manual configuration.

Reported-by: <>
Signed-off-by: Josh Boyer <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoxen/events: Mask a moving irq
Boris Ostrovsky [Fri, 18 Mar 2016 14:11:07 +0000 (10:11 -0400)]
xen/events: Mask a moving irq

commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream.

Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.

With 2-level this can happen as follows:

On source CPU:
        evtchn_2l_handle_events() ->
            generic_handle_irq() ->
                handle_edge_irq() ->

                       /***** WE ARE HERE *****/

                       if (VALID_EVTCHN(evtchn))

If at this moment target processor is handling an unrelated event in
evtchn_2l_handle_events()'s loop it may pick up our event since target's
cpu_evtchn_mask claims that this event belongs to it *and* the event is
unmasked and still pending. At the same time, source CPU will continue
executing its own handle_edge_irq().

With FIFO interrupt the scenario is similar: irq_move_irq() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.

We can avoid this situation by moving and clearing the event while
keeping event masked.

Signed-off-by: Boris Ostrovsky <>
Signed-off-by: David Vrabel <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Add a suitable definition of test_and_set_mask()]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: timer: Use mod_timer() for rearming the system timer
Takashi Iwai [Fri, 1 Apr 2016 10:28:16 +0000 (12:28 +0200)]
ALSA: timer: Use mod_timer() for rearming the system timer

commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream.

ALSA system timer backend stops the timer via del_timer() without sync
and leaves del_timer_sync() at the close instead.  This is because of
the restriction by the design of ALSA timer: namely, the stop callback
may be called from the timer handler, and calling the sync shall lead
to a hangup.  However, this also triggers a kernel BUG() when the
timer is rearmed immediately after stopping without sync:
 kernel BUG at kernel/time/timer.c:966!
 Call Trace:
  [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
  [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
  [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
  [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
  [<ffffffff81296b72>] call_timer_fn+0x162/0x520
  [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
  [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0

It's the place where add_timer() checks the pending timer.  It's clear
that this may happen after the immediate restart without sync in our

So, the workaround here is just to use mod_timer() instead of
add_timer().  This looks like a band-aid fix, but it's a right move,
as snd_timer_interrupt() takes care of the continuous rearm of timer.

Reported-by: Jiri Slaby <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: x86: Inject pending interrupt even if pending nmi exist
Yuki Shibuya [Thu, 24 Mar 2016 05:17:03 +0000 (05:17 +0000)]
KVM: x86: Inject pending interrupt even if pending nmi exist

commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 upstream.

Non maskable interrupts (NMI) are preferred to interrupts in current
implementation. If a NMI is pending and NMI is blocked by the result
of nmi_allowed(), pending interrupt is not injected and
enable_irq_window() is not executed, even if interrupts injection is

In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
In this case, interrupts are needed to execute iret that intends end
of NMI. The flag of blocking new NMI is not cleared until the guest
execute the iret, and interrupts are blocked by pending NMI. Due to
this, iret can't be invoked in the guest, and the guest is starved
until block is cleared by some events (e.g. canceling injection).

This patch injects pending interrupts, when it's allowed, even if NMI
is blocked. And, If an interrupts is pending after executing
inject_pending_event(), enable_irq_window() is executed regardless of
NMI pending counter.

Signed-off-by: Yuki Shibuya <>
Suggested-by: Paolo Bonzini <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - vcpu_enter_guest() is simpler because inject_pending_event() can't fail
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agosd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes
Martin K. Petersen [Tue, 29 Mar 2016 01:18:56 +0000 (21:18 -0400)]
sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes

commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream.

During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.

The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery

Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S

Signed-off-by: Martin K. Petersen <>
Reported-by: Hannes Reinecke <>
Reviewed-by: Hannes Reinicke <>
Reviewed-by: Ewan Milne <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2:
 - logical_to_sectors() is a new function
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: digi_acceleport: do sanity checking for the number of ports
Oliver Neukum [Thu, 31 Mar 2016 16:04:26 +0000 (12:04 -0400)]
USB: digi_acceleport: do sanity checking for the number of ports

commit 5a07975ad0a36708c6b0a5b9fea1ff811d0b0c1f upstream.

The driver can be crashed with devices that expose crafted descriptors
with too few endpoints.


Signed-off-by: Oliver Neukum <>
[johan: fix OOB endpoint check and add error messages ]
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: cypress_m8: add endpoint sanity check
Oliver Neukum [Thu, 31 Mar 2016 16:04:25 +0000 (12:04 -0400)]
USB: cypress_m8: add endpoint sanity check

commit c55aee1bf0e6b6feec8b2927b43f7a09a6d5f754 upstream.

An attack using missing endpoints exists.


Signed-off-by: Oliver Neukum <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: mct_u232: add sanity checking in probe
Oliver Neukum [Thu, 31 Mar 2016 16:04:24 +0000 (12:04 -0400)]
USB: mct_u232: add sanity checking in probe

commit 4e9a0b05257f29cf4b75f3209243ed71614d062e upstream.

An attack using the lack of sanity checking in probe is known. This
patch checks for the existence of a second port.


Signed-off-by: Oliver Neukum <>
[johan: add error message ]
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: put the check in mct_u232_startup(), which already
 has a 'serial' variable]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream()...
Vladis Dronov [Thu, 31 Mar 2016 16:05:43 +0000 (12:05 -0400)]
ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call

commit 836b34a935abc91e13e63053d0a83b24dfb5ea78 upstream.

create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
create_uaxx_quirk() functions allocate the audioformat object by themselves
and free it upon error before returning. However, once the object is linked
to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
double-freed, eventually resulting in a memory corruption.

This patch fixes these failures in the error paths by unlinking the audioformat
object before freeing it.

Based on a patch by Takashi Iwai <>

[Note for stable backports:
 this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor
 code cleanup in create_fixed_stream_quirk()')]

Reported-by: Ralf Spenneberg <>
Signed-off-by: Vladis Dronov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()
Takashi Iwai [Tue, 15 Mar 2016 11:14:49 +0000 (12:14 +0100)]
ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()

commit 902eb7fd1e4af3ac69b9b30f8373f118c92b9729 upstream.

Just a minor code cleanup: unify the error paths.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
Yoshihiro Shimoda [Thu, 10 Mar 2016 02:30:15 +0000 (11:30 +0900)]
usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer

commit 6490865c67825277b29638e839850882600b48ec upstream.

This patch adds a code to surely disable TX IRQ of the pipe before
starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
may happen in rare cases when DMAC is used.

Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
Yoshihiro Shimoda [Thu, 10 Mar 2016 02:30:14 +0000 (11:30 +0900)]
usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()

commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream.

When unexpected situation happened (e.g. tx/rx irq happened while
DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
pointer dereference like the followings:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial g_serial libcomposite
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
Hardware name: Generic R8A7790 (Flattened Device Tree)
task: c0729c00 ti: c0724000 task.ti: c0724000
PC is at 0x0
LR is at usbhsf_pkt_handler+0xac/0x118
pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
sp : c0725db8  ip : 00000000  fp : c0725df4
r10: 00000001  r9 : 00000193  r8 : ef3ccab4
r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4

This patch adds a condition to avoid the dereference.

Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated
Guenter Roeck [Sat, 26 Mar 2016 19:28:05 +0000 (12:28 -0700)]
hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated

commit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f upstream.

arm:pxa_defconfig can result in the following crash if the max1111 driver
is not instantiated.

Unhandled fault: page domain fault (0x01b) at 0x00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: : 1b [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10
Hardware name: SHARP Akita
Workqueue: events sharpsl_charge_toggle
task: c390a000 ti: c391e000 task.ti: c391e000
PC is at max1111_read_channel+0x20/0x30
LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
[<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
[<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
[<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
[<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
[<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
[<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
[<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
[<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)

This can occur because the SPI controller driver (SPI_PXA2XX) is built as
module and thus not necessarily loaded. While building SPI_PXA2XX into the
kernel would make the problem disappear, it appears prudent to ensure that
the driver is instantiated before accessing its data structures.

Cc: Arnd Bergmann <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agoocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list
Joseph Qi [Fri, 25 Mar 2016 21:21:29 +0000 (14:21 -0700)]
ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list

commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream.

When master handles convert request, it queues ast first and then
returns status.  This may happen that the ast is sent before the request
status because the above two messages are sent by two threads.  And
right after the ast is sent, if master down, it may trigger BUG in
dlm_move_lockres_to_recovery_list in the requested node because ast
handler moves it to grant list without clear lock->convert_pending.  So
remove BUG_ON statement and check if the ast is processed in

Signed-off-by: Joseph Qi <>
Reported-by: Yiwen Jiang <>
Cc: Junxiao Bi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Tariq Saeed <>
Cc: Junxiao Bi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoocfs2/dlm: fix race between convert and recovery
Joseph Qi [Fri, 25 Mar 2016 21:21:26 +0000 (14:21 -0700)]
ocfs2/dlm: fix race between convert and recovery

commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac upstream.

There is a race window between dlmconvert_remote and
dlm_move_lockres_to_recovery_list, which will cause a lock with
OCFS2_LOCK_BUSY in grant list, thus system hangs.

        list_move_tail(&lock->list, &res->converting);
        lock->convert_pending = 1;

        status = dlm_send_remote_convert_request();
        >>>>>> race window, master has queued ast and return DLM_NORMAL,
               and then down before sending ast.
               this node detects master down and calls
               dlm_move_lockres_to_recovery_list, which will revert the
               lock to grant list.
               Then OCFS2_LOCK_BUSY won't be cleared as new master won't
               send ast any more because it thinks already be authorized.

        lock->convert_pending = 0;
        if (status != DLM_NORMAL)
                dlm_revert_pending_convert(res, lock);

In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set
(res is still in recovering) or res master changed (new master has
finished recovery), reset the status to DLM_RECOVERING, then it will
retry convert.

Signed-off-by: Joseph Qi <>
Reported-by: Yiwen Jiang <>
Reviewed-by: Junxiao Bi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Tariq Saeed <>
Cc: Junxiao Bi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoMAINTAINERS: Update mailing list and web page for hwmon subsystem
Guenter Roeck [Tue, 22 Mar 2016 22:11:03 +0000 (15:11 -0700)]
MAINTAINERS: Update mailing list and web page for hwmon subsystem

commit 968ce1b1f45a7d76b5471b19bd035dbecc72f32d upstream.

The old web page for the hwmon subsystem is no longer operational,
and the mailing list has become unreliable. Move both to

Reviewed-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2: the set of hwmon drivers is different, so do a
 search-and-replace for the same addresses]
Signed-off-by: Ben Hutchings <>
7 years agoInput: ati_remote2 - fix crashes on detecting device with invalid descriptor
Vladis Dronov [Wed, 23 Mar 2016 18:53:46 +0000 (11:53 -0700)]
Input: ati_remote2 - fix crashes on detecting device with invalid descriptor

commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream.

The ati_remote2 driver expects at least two interfaces with one
endpoint each. If given malicious descriptor that specify one
interface or no endpoints, it will crash in the probe function.
Ensure there is at least two interfaces and one endpoint for each
interface before using it.

The full disclosure:

Reported-by: Ralf Spenneberg <>
Signed-off-by: Vladis Dronov <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoppp: take reference on channels netns
Guillaume Nault [Wed, 23 Mar 2016 15:38:55 +0000 (16:38 +0100)]
ppp: take reference on channels netns

commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89 upstream.

Let channels hold a reference on their network namespace.
Some channel types, like ppp_async and ppp_synctty, can have their
userspace controller running in a different namespace. Therefore they
can't rely on them to preclude their netns from being removed from
under them.

BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
addr ffff880064e217e0
Read of size 8 by task syz-executor/11581
BUG net_namespace (Not tainted): kasan: bad access detected

Disabling lock debugging due to kernel taint
INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
[<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
[<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
[<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
[<     inline     >] slab_alloc kernel/mm/slub.c:2574
[<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
[<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
[<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
[<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
[<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
[<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
[<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
[<     inline     >] copy_process kernel/kernel/fork.c:1274
[<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
[<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
[<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
[<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185

INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
[<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
[<     inline     >] slab_free kernel/mm/slub.c:2805
[<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
[<     inline     >] net_free kernel/net/core/net_namespace.c:341
[<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
[<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
[<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
[<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
[<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
[<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200

CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.2-0-g33fbe13 by 04/01/2014
 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
 ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
 ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
Call Trace:
 [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
 [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
 [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
 [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
 [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
 [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
 [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
 [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
 [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
 [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
 [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
 [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
 [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
 [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
 [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
 [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
 [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
 [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
 [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
 [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
 [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
 [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
 [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
 [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
 [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
 [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
 [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
 [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
 [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
 [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
 [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
 [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
 [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
 [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
 [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
 [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
 [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
 [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
 [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
 [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
 [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
 [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
 [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
 [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
 [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
 [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
Memory state around the buggy address:
 ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2")
Reported-by: Baozeng Ding <>
Signed-off-by: Guillaume Nault <>
Reviewed-by: Cyrill Gorcunov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agorapidio/rionet: fix deadlock on SMP
Aurelien Jacquiot [Tue, 22 Mar 2016 21:25:42 +0000 (14:25 -0700)]
rapidio/rionet: fix deadlock on SMP

commit 36915976eca58f2eefa040ba8f9939672564df61 upstream.

Fix deadlocking during concurrent receive and transmit operations on SMP
platforms caused by the use of incorrect lock: on transmit 'tx_lock'
spinlock should be used instead of 'lock' which is used for receive

This fix is applicable to kernel versions starting from v2.15.

Signed-off-by: Aurelien Jacquiot <>
Signed-off-by: Alexandre Bounine <>
Cc: Matt Porter <>
Cc: Andre van Herk <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agofs/coredump: prevent fsuid=0 dumps into user-controlled directories
Jann Horn [Tue, 22 Mar 2016 21:25:36 +0000 (14:25 -0700)]
fs/coredump: prevent fsuid=0 dumps into user-controlled directories

commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream.

This commit fixes the following security hole affecting systems where
all of the following conditions are fulfilled:

 - The fs.suid_dumpable sysctl is set to 2.
 - The kernel.core_pattern sysctl's value starts with "/". (Systems
   where kernel.core_pattern starts with "|/" are not affected.)
 - Unprivileged user namespace creation is permitted. (This is
   true on Linux >=3.8, but some distributions disallow it by
   default using a distro patch.)

Under these conditions, if a program executes under secure exec rules,
causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
namespace, changes its root directory and crashes, the coredump will be
written using fsuid=0 and a path derived from kernel.core_pattern - but
this path is interpreted relative to the root directory of the process,
allowing the attacker to control where a coredump will be written with
root privileges.

To fix the security issue, always interpret core_pattern for dumps that
are written under SUID_DUMP_ROOT relative to the root directory of init.

Signed-off-by: Jann Horn <>
Acked-by: Kees Cook <>
Cc: Al Viro <>
Cc: "Eric W. Biederman" <>
Cc: Andy Lutomirski <>
Cc: Oleg Nesterov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agoethernet: micrel: fix some error codes
Dan Carpenter [Wed, 16 Mar 2016 07:45:10 +0000 (10:45 +0300)]
ethernet: micrel: fix some error codes

commit 3af0d554c1ce11e9d0953381ff566271f9ab81a9 upstream.

There were two issues here:
1) dma_mapping_error() return true/false but we want to return -ENOMEM
2) If dmaengine_prep_slave_sg() failed then "err" wasn't set but
   presumably that should be -ENOMEM as well.

I changed the success path to "return 0;" instead of "return ret;" for

Fixes: 94fe8c683cea ('ks8842: Support DMA when accessed via timberdale')
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agosplice: handle zero nr_pages in splice_to_pipe()
Rabin Vincent [Thu, 10 Mar 2016 20:19:06 +0000 (21:19 +0100)]
splice: handle zero nr_pages in splice_to_pipe()

commit d6785d9152147596f60234157da2b02540c3e60f upstream.

Running the following command:

 busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null

with any tracing enabled pretty very quickly leads to various NULL
pointer dereferences and VM BUG_ON()s, such as these:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
 IP: [<ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
 Call Trace:
  [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
  [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
  [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
  [<ffffffff81196869>] do_sendfile+0x199/0x380
  [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
  [<ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d

 page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
 kernel BUG at include/linux/mm.h:367!
 invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 RIP: [<ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
 Call Trace:
  [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
  [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
  [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
  [<ffffffff81196869>] do_sendfile+0x199/0x380
  [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
  [<ffffffff8192cd1e>] tracesys_phase2+0x84/0x89

(busybox's cat uses sendfile(2), unlike the coreutils version)

This is because tracing_splice_read_pipe() can call splice_to_pipe()
with spd->nr_pages == 0.  spd_pages underflows in splice_to_pipe() and
we fill the page pointers and the other fields of the pipe_buffers with

All other callers of splice_to_pipe() avoid calling it when nr_pages ==
0, and we could make tracing_splice_read_pipe() do that too, but it
seems reasonable to have splice_to_page() handle this condition

Signed-off-by: Rabin Vincent <>
Reviewed-by: Christoph Hellwig <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
7 years agotracing: Fix crash from reading trace_pipe with sendfile
Steven Rostedt (Red Hat) [Fri, 18 Mar 2016 19:46:48 +0000 (15:46 -0400)]
tracing: Fix crash from reading trace_pipe with sendfile

commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.

If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.

There's a patch to fix this in the splice_to_pipe() code, but it's also a
good idea to not let that happen from trace_pipe either.

Reported-by: Rabin Vincent <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
7 years agolpfc: fix misleading indentation
Arnd Bergmann [Mon, 14 Mar 2016 14:29:44 +0000 (15:29 +0100)]
lpfc: fix misleading indentation

commit aeb6641f8ebdd61939f462a8255b316f9bfab707 upstream.

gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array()
call in lpfc_online(), which clearly doesn't look right:

drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online':
drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
   lpfc_destroy_vport_work_array(phba, vports);
drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not
  if (vports != NULL)

Looking at the patch that introduced this code, it's clear that the
behavior is correct and the indentation is wrong.

This fixes the indentation and adds curly braces around the previous
if() block for clarity, as that is most likely what caused the code
to be misindented in the first place.

Signed-off-by: Arnd Bergmann <>
Fixes: 549e55cd2a1b ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
Reviewed-by: Sebastian Herbszt <>
Reviewed-by: Hannes Reinecke <>
Reviewed-by: Ewan D. Milne <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
7 years agotracing: Have preempt(irqs)off trace preempt disabled functions
Steven Rostedt (Red Hat) [Fri, 18 Mar 2016 16:27:43 +0000 (12:27 -0400)]
tracing: Have preempt(irqs)off trace preempt disabled functions

commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream.

Joel Fernandes reported that the function tracing of preempt disabled
sections was not being reported when running either the preemptirqsoff or
preemptoff tracers. This was due to the fact that the function tracer
callback for those tracers checked if irqs were disabled before tracing. But
this fails when we want to trace preempt off locations as well.

Joel explained that he wanted to see funcitons where interrupts are enabled
but preemption was disabled. The expected output he wanted:

   <...>-2265    1d.h1 3419us : preempt_count_sub <-irq_exit
   <...>-2265    1d..1 3419us : __do_softirq <-irq_exit
   <...>-2265    1d..1 3419us : msecs_to_jiffies <-__do_softirq
   <...>-2265    1d..1 3420us : irqtime_account_irq <-__do_softirq
   <...>-2265    1d..1 3420us : __local_bh_disable_ip <-__do_softirq
   <...>-2265    1..s1 3421us : run_timer_softirq <-__do_softirq
   <...>-2265    1..s1 3421us : hrtimer_run_pending <-run_timer_softirq
   <...>-2265    1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq
   <...>-2265    1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq
   <...>-2265    1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq
   <...>-2265    1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq
   <...>-2265    1..s1 3423us : rcu_bh_qs <-__do_softirq
   <...>-2265    1d.s1 3423us : irqtime_account_irq <-__do_softirq
   <...>-2265    1d.s1 3423us : __local_bh_enable <-__do_softirq

There's a comment saying that the irq disabled check is because there's a
possible race that tracing_cpu may be set when the function is executed. But
I don't remember that race. For now, I added a check for preemption being
enabled too to not record the function, as there would be no race if that
was the case. I need to re-investigate this, as I'm now thinking that the
tracing_cpu will always be correct. But no harm in keeping the check for
now, except for the slight performance hit.

Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers"
Cc: # 2.6.37+
Reported-by: Joel Fernandes <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: cdc-acm: more sanity checking
Oliver Neukum [Tue, 15 Mar 2016 09:14:04 +0000 (10:14 +0100)]
USB: cdc-acm: more sanity checking

commit 8835ba4a39cf53f705417b3b3a94eb067673f2c9 upstream.

An attack has become available which pretends to be a quirky
device circumventing normal sanity checks and crashes the kernel
by an insufficient number of interfaces. This patch adds a check
to the code path for quirky devices.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_driver_claim_interface: add sanity checking
Oliver Neukum [Wed, 16 Mar 2016 12:26:17 +0000 (13:26 +0100)]
USB: usb_driver_claim_interface: add sanity checking

commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd upstream.

Attacks that trick drivers into passing a NULL pointer
to usb_driver_claim_interface() using forged descriptors are
known. This thwarts them by sanity checking.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: iowarrior: fix oops with malicious USB descriptors
Josh Boyer [Mon, 14 Mar 2016 14:42:38 +0000 (10:42 -0400)]
USB: iowarrior: fix oops with malicious USB descriptors

commit 4ec0ef3a82125efc36173062a50624550a900ae0 upstream.

The iowarrior driver expects at least one valid endpoint.  If given
malicious descriptors that specify 0 for the number of endpoints,
it will crash in the probe function.  Ensure there is at least
one endpoint on the interface before using it.

The full report of this issue can be found here:

Reported-by: Ralf Spenneberg <>
Signed-off-by: Josh Boyer <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - handle spurious release of trackstick buttons, again
Benjamin Tissoires [Fri, 18 Mar 2016 00:12:54 +0000 (17:12 -0700)]
Input: synaptics - handle spurious release of trackstick buttons, again

commit 82be788c96ed5978d3cb4a00079e26b981a3df3f upstream.

Looks like the fimware 8.2 still has the extra buttons spurious release

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoraid10: include bio_end_io_list in nr_queued to prevent freeze_array hang
Shaohua Li [Mon, 14 Mar 2016 18:49:32 +0000 (11:49 -0700)]
raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang

commit 23ddba80ebe836476bb2fa1f5ef305dd1c63dc0b upstream.

This is the raid10 counterpart of the bug fixed by Nate
(raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang)

Fixes: 95af587e95(md/raid10: ensure device failure recorded before write request returns)
Cc: Nate Dailey <>
Signed-off-by: Shaohua Li <>
Signed-off-by: Ben Hutchings <>
7 years agoraid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
Nate Dailey [Mon, 29 Feb 2016 15:43:58 +0000 (10:43 -0500)]
raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang

commit ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb upstream.

If raid1d is handling a mix of read and write errors, handle_read_error's
call to freeze_array can get stuck.

This can happen because, though the bio_end_io_list is initially drained,
writes can be added to it via handle_write_finished as the retry_list
is processed. These writes contribute to nr_pending but are not included
in nr_queued.

If a later entry on the retry_list triggers a call to handle_read_error,
freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
on the bio_end_io_list aren't included in nr_queued so the condition will
never be satisfied.

To prevent the hang, include bio_end_io_list writes in nr_queued.

There's probably a better way to handle decrementing nr_queued, but this
seemed like the safest way to avoid breaking surrounding code.

I'm happy to supply the script I used to repro this hang.

Fixes: 55ce74d4bfe1b(md/raid1: ensure device failure recorded before write request returns.)
Signed-off-by: Nate Dailey <>
Signed-off-by: Shaohua Li <>
Signed-off-by: Ben Hutchings <>
7 years agox86/iopl: Fix iopl capability check on Xen PV
Andy Lutomirski [Wed, 16 Mar 2016 21:14:22 +0000 (14:14 -0700)]
x86/iopl: Fix iopl capability check on Xen PV

commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e upstream.

iopl(3) is supposed to work if iopl is already 3, even if
unprivileged.  This didn't work right on Xen PV.  Fix it.

Reviewewd-by: Jan Beulich <>
Signed-off-by: Andy Lutomirski <>
Cc: Andrew Cooper <>
Cc: Andy Lutomirski <>
Cc: Boris Ostrovsky <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: David Vrabel <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Jan Beulich <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agox86/iopl/64: Properly context-switch IOPL on Xen PV
Andy Lutomirski [Wed, 16 Mar 2016 21:14:21 +0000 (14:14 -0700)]
x86/iopl/64: Properly context-switch IOPL on Xen PV

commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.

On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL.  We need to context
switch it manually.

I'm doing this without going through paravirt because this is
specific to Xen PV.  After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.

Fixes XSA-171.

Reviewewd-by: Jan Beulich <>
Signed-off-by: Andy Lutomirski <>
Cc: Andrew Cooper <>
Cc: Andy Lutomirski <>
Cc: Boris Ostrovsky <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: David Vrabel <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Jan Beulich <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Use xen_pv_domain() directly as X86_FEATURE_XENPV is not defined
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoppp: ensure file->private_data can't be overridden
Guillaume Nault [Mon, 14 Mar 2016 20:17:16 +0000 (21:17 +0100)]
ppp: ensure file->private_data can't be overridden

commit e8e56ffd9d2973398b60ece1f1bebb8d67b4d032 upstream.

Locking ppp_mutex must be done before dereferencing file->private_data,
otherwise it could be modified before ppp_unattached_ioctl() takes the
lock. This could lead ppp_unattached_ioctl() to override ->private_data,
thus leaking reference to the ppp_file previously pointed to.

v2: lock all ppp_ioctl() instead of just checking private_data in
    ppp_unattached_ioctl(), to avoid ambiguous behaviour.

Fixes: f3ff8a4d80e8 ("ppp: push BKL down into the driver")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonfsd: fix deadlock secinfo+readdir compound
J. Bruce Fields [Thu, 3 Mar 2016 00:36:21 +0000 (16:36 -0800)]
nfsd: fix deadlock secinfo+readdir compound

commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 upstream.

nfsd_lookup_dentry exits with the parent filehandle locked.  fh_put also
unlocks if necessary (nfsd filehandle locking is probably too lenient),
so it gets unlocked eventually, but if the following op in the compound
needs to lock it again, we can deadlock.

A fuzzer ran into this; normal clients don't send a secinfo followed by
a readdir in the same compound.

Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: usb-audio: Add sanity checks for endpoint accesses
Takashi Iwai [Tue, 15 Mar 2016 14:20:58 +0000 (15:20 +0100)]
ALSA: usb-audio: Add sanity checks for endpoint accesses

commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a upstream.

Add some sanity check codes before actually accessing the endpoint via
get_endpoint() in order to avoid the invalid access through a
malformed USB descriptor.  Mostly just checking bNumEndpoints, but in
one place (snd_microii_spdif_default_get()), the validity of iface and
altsetting index is checked as well.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: drop changes to code we don't have]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk()
Takashi Iwai [Tue, 15 Mar 2016 11:09:10 +0000 (12:09 +0100)]
ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk()

commit 0f886ca12765d20124bd06291c82951fd49a33be upstream.

create_fixed_stream_quirk() may cause a NULL-pointer dereference by
accessing the non-existing endpoint when a USB device with a malformed
USB descriptor is used.

This patch avoids it simply by adding a sanity check of bNumEndpoints
before the accesses.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2:
 - There's no altsd variable
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoath9k: fix buffer overrun for ar9287
Arnd Bergmann [Mon, 14 Mar 2016 14:18:36 +0000 (15:18 +0100)]
ath9k: fix buffer overrun for ar9287

commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 upstream.

Code that was added back in 2.6.38 has an obvious overflow
when accessing a static array, and at the time it was added
only a code comment was put in front of it as a reminder
to have it reviewed properly.

This has not happened, but gcc-6 now points to the specific

drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
     maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];

It turns out that the correct array length exists in the local
'intercepts' variable of this function, so we can just use that
instead of hardcoding '4', so this patch changes all three
instances to use that variable. The other two instances were
already correct, but it's more consistent this way.

Signed-off-by: Arnd Bergmann <>
Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: Fix use after free in the recvmmsg exit path
Arnaldo Carvalho de Melo [Mon, 14 Mar 2016 12:56:35 +0000 (09:56 -0300)]
net: Fix use after free in the recvmmsg exit path

commit 34b88a68f26a75e4fded796f1a49c40f82234b7d upstream.

The syzkaller fuzzer hit the following use-after-free:

  Call Trace:
   [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
   [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
   [<     inline     >] SYSC_recvmmsg net/socket.c:2281
   [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
   [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a

And, as Dmitry rightly assessed, that is because we can drop the
reference and then touch it when the underlying recvmsg calls return
some packets and then hit an error, which will make recvmmsg to set
sock->sk->sk_err, oops, fix it.

Reported-and-Tested-by: Dmitry Vyukov <>
Cc: Alexander Potapenko <>
Cc: Eric Dumazet <>
Cc: Kostya Serebryany <>
Cc: Sasha Levin <>
Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall")
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: powermate - fix oops with malicious USB descriptors
Josh Boyer [Mon, 14 Mar 2016 16:33:40 +0000 (09:33 -0700)]
Input: powermate - fix oops with malicious USB descriptors

commit 9c6ba456711687b794dcf285856fc14e2c76074f upstream.

The powermate driver expects at least one valid USB endpoint in its
probe function.  If given malicious descriptors that specify 0 for
the number of endpoints, it will crash.  Validate the number of
endpoints on the interface before using them.

The full report for this issue can be found here:

Reported-by: Ralf Spenneberg <>
Signed-off-by: Josh Boyer <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agortc: vr41xx: Wire up alarm_irq_enable
Geert Uytterhoeven [Tue, 1 Mar 2016 08:50:01 +0000 (09:50 +0100)]
rtc: vr41xx: Wire up alarm_irq_enable

commit a25f4a95ec3cded34c1250364eba704c5e4fdac4 upstream.

drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used

Apparently the conversion to alarm_irq_enable forgot to wire up the

Fixes: 16380c153a69c378 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Alexandre Belloni <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41.
Vittorio Gambaletta (VittGam) [Sun, 13 Mar 2016 21:19:34 +0000 (22:19 +0100)]
ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41.

commit 4061db03dd71d195b9973ee466f6ed32f6a3fc16 upstream.

The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
will often fail, so add a quirk entry to fix it.

Signed-off-by: Vittorio Gambaletta <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agodm snapshot: disallow the COW and origin devices from being identical
DingXiang [Tue, 2 Feb 2016 04:29:18 +0000 (12:29 +0800)]
dm snapshot: disallow the COW and origin devices from being identical

commit 4df2bf466a9c9c92f40d27c4aa9120f4e8227bfc upstream.

Otherwise loading a "snapshot" table using the same device for the
origin and COW devices, e.g.:

echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap

will trigger:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[ 1958.979934] IP: [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1958.989655] PGD 0
[ 1958.991903] Oops: 0000 [#1] SMP
[ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G          IO    4.5.0-rc5.snitm+ #150
[ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000
[ 1959.091865] RIP: 0010:[<ffffffffa040efba>]  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1959.104295] RSP: 0018:ffff88032a957b30  EFLAGS: 00010246
[ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001
[ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00
[ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001
[ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80
[ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80
[ 1959.150021] FS:  00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000
[ 1959.159047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0
[ 1959.173415] Stack:
[ 1959.175656]  ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc
[ 1959.183946]  ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000
[ 1959.192233]  ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf
[ 1959.200521] Call Trace:
[ 1959.203248]  [<ffffffffa040f225>] dm_exception_store_create+0x1d5/0x240 [dm_snapshot]
[ 1959.211986]  [<ffffffffa040d310>] snapshot_ctr+0x140/0x630 [dm_snapshot]
[ 1959.219469]  [<ffffffffa0005c44>] ? dm_split_args+0x64/0x150 [dm_mod]
[ 1959.226656]  [<ffffffffa0005ea7>] dm_table_add_target+0x177/0x440 [dm_mod]
[ 1959.234328]  [<ffffffffa0009203>] table_load+0x143/0x370 [dm_mod]
[ 1959.241129]  [<ffffffffa00090c0>] ? retrieve_status+0x1b0/0x1b0 [dm_mod]
[ 1959.248607]  [<ffffffffa0009e35>] ctl_ioctl+0x255/0x4d0 [dm_mod]
[ 1959.255307]  [<ffffffff813304e2>] ? memzero_explicit+0x12/0x20
[ 1959.261816]  [<ffffffffa000a0c3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
[ 1959.268615]  [<ffffffff81215eb6>] do_vfs_ioctl+0xa6/0x5c0
[ 1959.274637]  [<ffffffff81120d2f>] ? __audit_syscall_entry+0xaf/0x100
[ 1959.281726]  [<ffffffff81003176>] ? do_audit_syscall_entry+0x66/0x70
[ 1959.288814]  [<ffffffff81216449>] SyS_ioctl+0x79/0x90
[ 1959.294450]  [<ffffffff8167e4ae>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1959.323277] RIP  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1959.333090]  RSP <ffff88032a957b30>
[ 1959.336978] CR2: 0000000000000098
[ 1959.344121] ---[ end trace b049991ccad1169e ]---

Signed-off-by: Ding Xiang <>
Signed-off-by: Mike Snitzer <>
[bwh: Backported to 3.2: the device path parsing code is rather different,
 but move it into dm_get_dev_t() anyway]
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: btusb: Add a new AR3012 ID 13d3:3472
Dmitry Tunin [Thu, 3 Mar 2016 22:32:19 +0000 (01:32 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 13d3:3472

commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3472 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
7 years agojbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path
OGAWA Hirofumi [Thu, 10 Mar 2016 04:47:25 +0000 (23:47 -0500)]
jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path

commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 upstream.

On umount path, jbd2_journal_destroy() writes latest transaction ID
(->j_tail_sequence) to be used at next mount.

The bug is that ->j_tail_sequence is not holding latest transaction ID
in some cases. So, at next mount, there is chance to conflict with
remaining (not overwritten yet) transactions.

mount (id=10)
write transaction (id=11)
write transaction (id=12)
umount (id=10) <= the bug doesn't write latest ID

mount (id=10)
write transaction (id=11)

[recovery process]
transaction (id=11)
transaction (id=12) <= valid transaction ID, but old commit
                                       must not replay

Like above, this bug become the cause of recovery failure, or FS

So why ->j_tail_sequence doesn't point latest ID?

Because if checkpoint transactions was reclaimed by memory pressure
(i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
(And another case is, __jbd2_journal_clean_checkpoint_list() is called
with empty transaction.)

So in above cases, ->j_tail_sequence is not pointing latest
transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
done too.

So, to fix this problem with minimum changes, this patch updates
->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
some optimizations would be possible to avoid unnecessary REQ_FLUSH
for example though.)


journal->j_tail_sequence =

Increment of ->j_transaction_sequence seems to be unnecessary, but
ext3 does this.

Signed-off-by: OGAWA Hirofumi <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
7 years agosg: fix dxferp in from_to case
Douglas Gilbert [Thu, 3 Mar 2016 05:31:29 +0000 (00:31 -0500)]
sg: fix dxferp in from_to case

commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream.

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Signed-off-by: Douglas Gilbert <>
Reviewed-by: Ewan Milne <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.
Mario Kleiner [Sun, 6 Mar 2016 01:39:53 +0000 (02:39 +0100)]
drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream.

As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.

Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.

Signed-off-by: Mario Kleiner <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
7 years agobe2iscsi: set the boot_kset pointer to NULL in case of failure
Maurizio Lombardi [Fri, 4 Mar 2016 09:41:49 +0000 (10:41 +0100)]
be2iscsi: set the boot_kset pointer to NULL in case of failure

commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream.

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Signed-off-by: Maurizio Lombardi <>
Reviewed-by: Johannes Thumshirn <>
Reviewed-by: Jitendra Bhivare <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
7 years agox86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs
Bjorn Helgaas [Fri, 26 Feb 2016 15:15:11 +0000 (09:15 -0600)]
x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs

commit b894157145e4ac7598d7062bc93320898a5e059e upstream.

The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
where a BAR should be.  We don't know what the side effects of sizing the
"BAR" would be, and we don't know what address space the "BAR" might appear
to describe.

Mark these devices as having non-compliant BARs so the PCI core doesn't
touch them.

Signed-off-by: Bjorn Helgaas <>
Tested-by: Andi Kleen <>
Signed-off-by: Ben Hutchings <>
7 years agoipvs: correct initial offset of Call-ID header search in SIP persistence engine
Marco Angaroni [Sat, 5 Mar 2016 11:10:02 +0000 (12:10 +0100)]
ipvs: correct initial offset of Call-ID header search in SIP persistence engine

commit 7617a24f83b5d67f4dab1844956be1cebc44aec8 upstream.

The IPVS SIP persistence engine is not able to parse the SIP header
"Call-ID" when such header is inserted in the first positions of
the SIP message.

When IPVS is configured with "--pe sip" option, like for example:
ipvsadm -A -u -s rr --pe sip -p 120 -o
some particular messages (see below for details) do not create entries
in the connection template table, which can be listed with:
ipvsadm -Lcn --persistent-conn

Problematic SIP messages are SIP responses having "Call-ID" header
positioned just after message first line:
SIP/2.0 200 OK
[Call-ID header here]
[rest of the headers]

When "Call-ID" header is positioned down (after a few other headers)
it is correctly recognized.

This is due to the data offset used in get_callid function call inside
ip_vs_pe_sip.c file: since dptr already points to the start of the
SIP message, the value of dataoff should be initially 0.
Otherwise the header is searched starting from some bytes after the
first character of the SIP message.

Fixes: 758ff0338722 ("IPVS: sip persistence engine")
Signed-off-by: Marco Angaroni <>
Acked-by: Julian Anastasov <>
Signed-off-by: Simon Horman <>
Signed-off-by: Ben Hutchings <>
7 years agosched/cputime: Fix steal time accounting vs. CPU hotplug
Thomas Gleixner [Fri, 4 Mar 2016 14:59:42 +0000 (15:59 +0100)]
sched/cputime: Fix steal time accounting vs. CPU hotplug

commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream.

On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time
value over CPU down and up. So after the CPU comes up again the delta
calculation in steal_account_process_tick() wreckages itself due to the
unsigned math:

 u64 steal = paravirt_steal_clock(smp_processor_id());

 steal -= this_rq()->prev_steal_time;

So if steal is smaller than rq->prev_steal_time we end up with an insane large
value which then gets added to rq->prev_steal_time, resulting in a permanent
wreckage of the accounting. As a consequence the per CPU stats in /proc/stat
become stale.

Nice trick to tell the world how idle the system is (100%) while the CPU is
100% busy running tasks. Though we prefer realistic numbers.

None of the accounting values which use a previous value to account for
fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity
check for prev_irq_time and prev_steal_time_rq, but that sanity check solely
deals with clock warps and limits the /proc/stat visible wreckage. The
prev_time values are still wrong.

Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.

Signed-off-by: Thomas Gleixner <>
Acked-by: Rik van Riel <>
Cc: Frederic Weisbecker <>
Cc: Glauber Costa <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Fixes: commit 095c0aa83e52 "sched: adjust scheduler cpu power for stolen time"
Fixes: commit aa483808516c "sched: Remove irq time from available CPU power"
Fixes: commit e6e6685accfa "KVM guest: Steal time accounting"
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filenames]
Signed-off-by: Ben Hutchings <>
7 years agoKVM: i8254: change PIT discard tick policy
Radim Krčmář [Wed, 2 Mar 2016 21:56:38 +0000 (22:56 +0100)]
KVM: i8254: change PIT discard tick policy

commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 upstream.

Discard policy uses ack_notifiers to prevent injection of PIT interrupts
before EOI from the last one.

This patch changes the policy to always try to deliver the interrupt,
which makes a difference when its vector is in ISR.
Old implementation would drop the interrupt, but proposed one injects to
IRR, like real hardware would.

The old policy breaks legacy NMI watchdogs, where PIT is used through
virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
thus a guest deadlock with disabled interrupts will stop NMIs.

Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
in modern systems.)

Even though there is a chance of regressions, I think we can fix the
LVT0 NMI bug without introducing a new tick policy.

Reported-by: Yuki Shibuya <>
Reviewed-by: Paolo Bonzini <>
Signed-off-by: Radim Krčmář <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - s/ps->reinject/ps->pit_timer.reinject/
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: hub: fix a typo in hub_port_init() leading to wrong logic
Oliver Neukum [Wed, 17 Feb 2016 10:52:43 +0000 (11:52 +0100)]
usb: hub: fix a typo in hub_port_init() leading to wrong logic

commit 0d5ce778c43bf888328231bcdce05d5c860655aa upstream.

A typo of j for i led to a logic bug. To rule out future
confusion, the variable names are made meaningful.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agodrivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors
Michael Hennerich [Mon, 22 Feb 2016 09:20:24 +0000 (10:20 +0100)]
drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors

commit f3df53e4d70b5736368a8fe8aa1bb70c1cb1f577 upstream.

Fix RDAC read back errors caused by a typo. Value must shift by 2.

Fixes: a4bd394956f2 ("drivers/misc/ad525x_dpot.c: new features")
Signed-off-by: Michael Hennerich <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoxfs: fix two memory leaks in xfs_attr_list.c error paths
Mateusz Guzik [Tue, 1 Mar 2016 22:51:09 +0000 (09:51 +1100)]
xfs: fix two memory leaks in xfs_attr_list.c error paths

commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream.

This plugs 2 trivial leaks in xfs_attr_shortform_list and

Signed-off-by: Mateusz Guzik <>
Reviewed-by: Eric Sandeen <>
Signed-off-by: Dave Chinner <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agonfsd4: fix bad bounds checking
J. Bruce Fields [Tue, 1 Mar 2016 01:21:21 +0000 (20:21 -0500)]
nfsd4: fix bad bounds checking

commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 upstream.

A number of spots in the xdr decoding follow a pattern like

n = be32_to_cpup(p++);
READ_BUF(n + 4);

where n is a u32.  The only bounds checking is done in READ_BUF itself,
but since it's checking (n + 4), it won't catch cases where n is very
large, (u32)(-4) or higher.  I'm not sure exactly what the consequences
are, but we've seen crashes soon after.

Instead, just break these up into two READ_BUF()s.

Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agowatchdog: rc32434_wdt: fix ioctl error handling
Michael S. Tsirkin [Sun, 28 Feb 2016 15:44:09 +0000 (17:44 +0200)]
watchdog: rc32434_wdt: fix ioctl error handling

commit 10e7ac22cdd4d211cef99afcb9371b70cb175be6 upstream.

Calling return copy_to_user(...) in an ioctl will not do the right thing
if there's a pagefault: copy_to_user returns the number of bytes not
copied in this case.

Fix up watchdog/rc32434_wdt to do
return copy_to_user(...)) ?  -EFAULT : 0;


Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Wim Van Sebroeck <>
Signed-off-by: Ben Hutchings <>
7 years agobttv: Width must be a multiple of 16 when capturing planar formats
Hans de Goede [Sun, 7 Feb 2016 11:24:29 +0000 (09:24 -0200)]
bttv: Width must be a multiple of 16 when capturing planar formats

commit 5c915c68763889f0183a1cc61c84bb228b60124a upstream.

On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max
size results in a solid green rectangle being captured (all colors 0 in

This turns out to be caused by max-width (924) not being a multiple of 16.

We've likely never hit this problem before since normally xawtv / tvtime,
etc. will prefer packed pixel formats. But when using a video card which
is using xf86-video-modesetting + glamor, only planar XVideo fmts are
available, and xawtv will chose a matching capture format to avoid needing
to do conversion, triggering the solid green window problem.

Signed-off-by: Hans de Goede <>
Acked-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: btusb: Add a new AR3012 ID 04ca:3014
Dmitry Tunin [Sun, 28 Feb 2016 08:04:06 +0000 (11:04 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 04ca:3014

commit 81d90442eac779938217c3444b240aa51fd3db47 upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3014 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
7 years agoPCI: Disable IO/MEM decoding for devices with non-compliant BARs
Bjorn Helgaas [Thu, 25 Feb 2016 20:35:57 +0000 (14:35 -0600)]
PCI: Disable IO/MEM decoding for devices with non-compliant BARs

commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas <>
Tested-by: Andi Kleen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomac80211: fix memory leak
Sudip Mukherjee [Tue, 2 Feb 2016 07:51:14 +0000 (13:21 +0530)]
mac80211: fix memory leak

commit ea32f065bd3e3e09f0bcb3042f1664caf6b3e233 upstream.

On error we jumped to the error label and returned the error code but we
missed releasing sinfo.

Fixes: 5fe74014172d ("mac80211: avoid excessive stack usage in sta_info")
Reviewed-by: Julian Calaby <>
Signed-off-by: Sudip Mukherjee <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: there's no out_err label but there is another
 error case that would leak sinfo]
Signed-off-by: Ben Hutchings <>
7 years agomac80211: avoid excessive stack usage in sta_info
Arnd Bergmann [Tue, 26 Jan 2016 22:05:31 +0000 (23:05 +0100)]
mac80211: avoid excessive stack usage in sta_info

commit 0ef049dc1167fe834d0ad5d63f89eddc5c70f6e4 upstream.

When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
function consumes more stack than normally, exceeding the
1024 byte limit on ARM:

net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

It turns out that there are two functions that put a 'struct station_info'
on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
this structure alone requires up to 792 bytes.

Hoping that both are called rarely enough, this replaces the
on-stack structure with a dynamic allocation, which unfortunately
requires some suboptimal error handling for out-of-memory.

The __sta_info_destroy_part2 function is actually affected by the
stack usage twice because it calls cfg80211_del_sta_sinfo(), which
has another instance of struct station_info on its stack.

Signed-off-by: Arnd Bergmann <>
Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events")
Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event")
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2:
 - There's only one instance to fix
 - Adjust context,indentation
 - Use 'return' instead of 'goto out_err']
Signed-off-by: Ben Hutchings <>
7 years agoaacraid: Fix memory leak in aac_fib_map_free
Raghava Aditya Renukunta [Wed, 3 Feb 2016 23:06:02 +0000 (15:06 -0800)]
aacraid: Fix memory leak in aac_fib_map_free

commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream.

aac_fib_map_free() calls pci_free_consistent() without checking that
dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).

Fixed by adding a check to make sure that dev->hw_fib_va and
dev->max_fib_size are not NULL and 0 respectively.

Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"

Signed-off-by: Raghava Aditya Renukunta <>
Reviewed-by: Johannes Thumshirn <>
Reviewed-by: Tomas Henzl <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: Add new AR3012 ID 0489:e095
Dmitry Tunin [Tue, 9 Feb 2016 21:49:11 +0000 (00:49 +0300)]
Bluetooth: Add new AR3012 ID 0489:e095

commit 28c971d82fb58ef7cba22e5308be6d2d2590473d upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e095 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

This device requires ar3k/AthrBT_0x31010100.dfu and
ar3k/ramps_0x31010100_40.dfu firmware files that are not in
linux-firmware yet.

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: btusb: Add new AR3012 ID 13d3:3395
Dmitry Tunin [Wed, 10 Feb 2016 12:33:17 +0000 (15:33 +0300)]
Bluetooth: btusb: Add new AR3012 ID 13d3:3395

commit 609574eb46335cfac1421a07c0505627cbbab1f0 upstream.

T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3395 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Reported-and-tested-by: Christopher Simerly <>
Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
7 years agosaa7134: Fix bytesperline not being set correctly for planar formats
Hans de Goede [Sun, 14 Feb 2016 19:51:37 +0000 (17:51 -0200)]
saa7134: Fix bytesperline not being set correctly for planar formats

commit 3e71da19f9dc22e39a755d6ae9678661abb66adc upstream.

bytesperline should be the bytesperline for the first plane for planar
formats, not that of all planes combined.

This fixes a crash in xawtv caused by the wrong bpl.

Reported-and-tested-by: Stas Sergeev <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agousb: retry reset if a device times out
Oliver Neukum [Wed, 10 Feb 2016 10:33:18 +0000 (11:33 +0100)]
usb: retry reset if a device times out

commit 264904ccc33c604d4b3141bbd33808152dfac45b upstream.

Some devices I got show an inability to operate right after
power on if they are already connected. They are beyond recovery
if the descriptors are requested multiple times. So in case of
a timeout we rather bail early and reset again. But it must be
done only on the first loop lest we get into a reset/time out
spiral that can be overcome with a retry.

This patch is a rework of a patch that fell through the cracks.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agonet: irda: Fix use-after-free in irtty_open()
Peter Hurley [Sun, 10 Jan 2016 01:48:45 +0000 (17:48 -0800)]
net: irda: Fix use-after-free in irtty_open()

commit 401879c57f01cbf2da204ad2e8db910525c6dbea upstream.

The N_IRDA line discipline may access the previous line discipline's closed
and already-fre private data on open [1].

The tty->disc_data field _never_ refers to valid data on entry to the
line discipline's open() method. Rather, the ldisc is expected to
initialize that field for its own use for the lifetime of the instance
(ie. from open() to close() only).

    BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr ffff8800331dd068
    Read of size 4 by task a.out/13960
    BUG kmalloc-512 (Tainted: G    B          ): kasan: bad access detected
    Call Trace:
     [<ffffffff815fa2ae>] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279
     [<ffffffff836938a2>] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436
     [<ffffffff829f1b80>] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447
     [<ffffffff829f21c0>] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567
     [<     inline     >] tiocsetd drivers/tty/tty_io.c:2650
     [<ffffffff829da49e>] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883
     [<     inline     >] vfs_ioctl fs/ioctl.c:43
     [<ffffffff816708ac>] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607
     [<     inline     >] SYSC_ioctl fs/ioctl.c:622
     [<ffffffff81671204>] SyS_ioctl+0x74/0x80 fs/ioctl.c:613
     [<ffffffff852a7876>] entry_SYSCALL_64_fastpath+0x16/0x7a

Reported-and-tested-by: Dmitry Vyukov <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years ago8250: use callbacks to access UART_DLL/UART_DLM
Sebastian Frias [Fri, 18 Dec 2015 16:40:05 +0000 (17:40 +0100)]
8250: use callbacks to access UART_DLL/UART_DLM

commit 0b41ce991052022c030fd868e03877700220b090 upstream.

Some UART HW has a single register combining UART_DLL/UART_DLM
(this was probably forgotten in the change that introduced the
callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9)

Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...")

Signed-off-by: Sebastian Frias <>
Reviewed-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust filename
 - We're using serial_{in,out}p for 8-bit I/O]
Signed-off-by: Ben Hutchings <>
7 years agopwc: Add USB id for Philips Spc880nc webcam
Hans de Goede [Fri, 22 Jan 2016 10:53:55 +0000 (08:53 -0200)]
pwc: Add USB id for Philips Spc880nc webcam

commit 7445e45d19a09e5269dc85f17f9635be29d2f76c upstream.

SPC 880NC PC camera discussions:,135688.0.html

Reported-by: Kikim <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoEDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr()
Dan Carpenter [Wed, 20 Jan 2016 09:54:51 +0000 (12:54 +0300)]
EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr()

commit 6f3508f61c814ee852c199988a62bd954c50dfc1 upstream.

dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug. This can possibly truncate the
upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS

Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: Dan Carpenter <>
Cc: Aravind Gopalakrishnan <>
Cc: linux-edac <>
Signed-off-by: Borislav Petkov <>
Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.79 v3.2.79
Ben Hutchings [Fri, 1 Apr 2016 00:54:38 +0000 (01:54 +0100)]
Linux 3.2.79

7 years agoHID: usbhid: fix recursive deadlock
Ioan-Adrian Ratiu [Fri, 20 Nov 2015 20:19:02 +0000 (22:19 +0200)]
HID: usbhid: fix recursive deadlock

commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.

The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).

The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().

There are two ways to get out of this deadlock:
    1. Make the drivers work "around" the ctrl critical region, in the
    wacom case for ex. by delaying the scheduling of the proximity read
    request itself to a workqueue.
    2. Shrink the critical region so the usbhid lock protects only the
    instructions which modify usbhid state, calling hid_input_report()
    with the spinlock unlocked, allowing the device driver to grab the
    lock first, finish and then grab the lock afterwards in hid_ctrl().

This patch implements the 2nd solution.

Signed-off-by: Ioan-Adrian Ratiu <>
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2: adjust context]
Cc: Jason Gerecke <>
Signed-off-by: Ben Hutchings <>
7 years agoinclude/linux/poison.h: fix LIST_POISON{1,2} offset
Vasily Kulikov [Wed, 9 Sep 2015 22:36:00 +0000 (15:36 -0700)]
include/linux/poison.h: fix LIST_POISON{1,2} offset

commit 8a5e5e02fc83aaf67053ab53b359af08c6c49aaf upstream.

Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space.  E.g.  on x86 "poison pointer space"
is located starting from 0x0.  Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.

The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu
uses only 0x10000).  There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted.  Changing it
to a smaller value solves the problem for small mmap_min_addr setups.

The values are suggested by Solar Designer:

Signed-off-by: Vasily Kulikov <>
Cc: Solar Designer <>
Cc: Thomas Gleixner <>
Cc: "Kirill A. Shutemov" <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: aiptek - fix crash on detecting device without endpoints
Vladis Dronov [Tue, 1 Dec 2015 21:09:17 +0000 (13:09 -0800)]
Input: aiptek - fix crash on detecting device without endpoints

commit 8e20cf2bce122ce9262d6034ee5d5b76fbb92f96 upstream.

The aiptek driver crashes in aiptek_probe() when a specially crafted USB
device without endpoints is detected. This fix adds a check that the device
has proper configuration expected by the driver. Also an error return value
is changed to more matching one in one of the error paths.

Reported-by: Ralf Spenneberg <>
Signed-off-by: Vladis Dronov <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>