5 years agoxhci: Manually give back cancelled URB if we can't queue it for cancel
Mathias Nyman [Tue, 28 Mar 2017 12:55:30 +0000 (15:55 +0300)]
xhci: Manually give back cancelled URB if we can't queue it for cancel

commit d3519b9d9606991a1305596348b6d690bfa3eb27 upstream.

xhci needs to take care of four scenarios when asked to cancel a URB.

1 URB is not queued or already given back.
  usb_hcd_check_unlink_urb() will return an error, we pass the error on

2 We fail to find xhci internal structures from urb private data such as
  virtual device and endpoint ring.
  Give back URB immediately, can't do anything about internal structures.

3 URB private data has valid pointers to xhci internal data, but host is
  not  responding.
  give back URB immedately and remove the URB from the endpoint lists.

4 Everyting is working
  add URB to cancel list, queue a command to stop the endpoint, after
  which the URB can be turned to no-op or skipped, removed from lists,
  and given back.

We failed to give back the urb in case 2 where the correct device and
endpoint pointers could not be retrieved from URB private data.

This caused a hang on Dell Inspiron 5558/0VNM2T at resume from suspend
as urb was never returned.

[  245.270505] INFO: task rtsx_usb_ms_1:254 blocked for more than 120 seconds.
[  245.272244]       Tainted: G        W       4.11.0-rc3-ARCH #2
[  245.273983] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  245.275737] rtsx_usb_ms_1   D    0   254      2 0x00000000
[  245.277524] Call Trace:
[  245.279278]  __schedule+0x2d3/0x8a0
[  245.281077]  schedule+0x3d/0x90
[  245.281961]  usb_kill_urb.part.3+0x6c/0xa0 [usbcore]
[  245.282861]  ? wake_atomic_t_function+0x60/0x60
[  245.283760]  usb_kill_urb+0x21/0x30 [usbcore]
[  245.284649]  usb_start_wait_urb+0xe5/0x170 [usbcore]
[  245.285541]  ? try_to_del_timer_sync+0x53/0x80
[  245.286434]  usb_bulk_msg+0xbd/0x160 [usbcore]
[  245.287326]  rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb]

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Move debug logging along with endpoint lookup
 - Adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoACPI: Fix incompatibility with mcount-based function graph tracing
Josh Poimboeuf [Thu, 16 Mar 2017 13:56:28 +0000 (08:56 -0500)]
ACPI: Fix incompatibility with mcount-based function graph tracing

commit 61b79e16c68d703dde58c25d3935d67210b7d71b upstream.

Paul Menzel reported a warning:

  WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0
  Bad frame pointer: expected f6919d98, received f6919db0
    from func acpi_pm_device_sleep_wake return to c43b6f9d

The warning means that function graph tracing is broken for the
acpi_pm_device_sleep_wake() function.  That's because the ACPI Makefile
unconditionally sets the '-Os' gcc flag to optimize for size.  That's an
issue because mcount-based function graph tracing is incompatible with
'-Os' on x86, thanks to the following gcc bug:

I have another patch pending which will ensure that mcount-based
function graph tracing is never used with CONFIG_CC_OPTIMIZE_FOR_SIZE on

But this patch is needed in addition to that one because the ACPI
Makefile overrides that config option for no apparent reason.  It has
had this flag since the beginning of git history, and there's no related
comment, so I don't know why it's there.  As far as I can tell, there's
no reason for it to be there.  The appropriate behavior is for it to
honor CONFIG_CC_OPTIMIZE_FOR_{SIZE,PERFORMANCE} like the rest of the

Reported-by: Paul Menzel <>
Signed-off-by: Josh Poimboeuf <>
Acked-by: Steven Rostedt (VMware) <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
5 years agoACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal
James Morse [Thu, 16 Mar 2017 14:30:39 +0000 (14:30 +0000)]
ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal

commit 7d64f82cceb21e6d95db312d284f5f195e120154 upstream.

When removing a GHES device notified by SCI, list_del_rcu() is used,
ghes_remove() should call synchronize_rcu() before it goes on to call
kfree(ghes), otherwise concurrent RCU readers may still hold this list
entry after it has been freed.

Signed-off-by: James Morse <>
Reviewed-by: "Huang, Ying" <>
Fixes: 81e88fdc432a (ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support)
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
5 years agovirtio_balloon: prevent uninitialized variable use
Arnd Bergmann [Tue, 28 Mar 2017 16:46:59 +0000 (18:46 +0200)]
virtio_balloon: prevent uninitialized variable use

commit f0bb2d50dfcc519f06f901aac88502be6ff1df2c upstream.

The latest gcc-7.0.1 snapshot reports a new warning:

virtio/virtio_balloon.c: In function 'update_balloon_stats':
virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in this function [-Werror=uninitialized]

This seems absolutely right, so we should add an extra check to
prevent copying uninitialized stack data into the statistics.
>From all I can tell, this has been broken since the statistics code
was originally added in 2.6.34.

Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Ladi Prosek <>
Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: Ben Hutchings <>
5 years agovirtio_balloon: init 1st buffer in stats vq
Ladi Prosek [Thu, 23 Mar 2017 07:04:18 +0000 (08:04 +0100)]
virtio_balloon: init 1st buffer in stats vq

commit fc8653228c8588a120f6b5dad6983b7b61ff669e upstream.

When init_vqs runs, virtio_balloon.stats is either uninitialized or
contains stale values. The host updates its state with garbage data
because it has no way of knowing that this is just a marker buffer
used for signaling.

This patch updates the stats before pushing the initial buffer.

Alternative fixes:
* Push an empty buffer in init_vqs. Not easily done with the current
  virtio implementation and violates the spec "Driver MUST supply the
  same subset of statistics in all buffers submitted to the statsq".
* Push a buffer with invalid tags in init_vqs. Violates the same
  spec clause, plus "invalid tag" is not really defined.

Note: the spec says:
When using the legacy interface, the device SHOULD ignore all values in
the first buffer in the statsq supplied by the driver after device
initialization. Note: Historically, drivers supplied an uninitialized
buffer in the first buffer.

Unfortunately QEMU does not seem to implement the recommendation
even for the legacy interface.

Signed-off-by: Ladi Prosek <>
Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: Ben Hutchings <>
5 years agonetfilter: nf_nat_snmp: Fix panic when snmp_trap_helper fails to register
Gao Feng [Sat, 25 Mar 2017 10:24:36 +0000 (18:24 +0800)]
netfilter: nf_nat_snmp: Fix panic when snmp_trap_helper fails to register

commit 75c689dca98851d65ef5a27e5ce26b625b68751c upstream.

In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp
helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So the
snmp_helper is never registered. But it still tries to unregister the
snmp_helper, it could cause the panic.

Now remove the useless snmp_helper and the unregister call in the
error handler.

Fixes: 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp helper")
Signed-off-by: Gao Feng <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
5 years agoIB/qib: fix false-postive maybe-uninitialized warning
Arnd Bergmann [Tue, 14 Mar 2017 12:18:45 +0000 (13:18 +0100)]
IB/qib: fix false-postive maybe-uninitialized warning

commit f6aafac184a3e46e919769dd4faa8bf0dc436534 upstream.

aarch64-linux-gcc-7 complains about code it doesn't fully understand:

drivers/infiniband/hw/qib/qib_iba7322.c: In function 'qib_7322_txchk_change':
include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code is right, and despite trying hard, I could not come up with a version
that I liked better than just adding a fake initialization here to shut up the

Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
Signed-off-by: Arnd Bergmann <>
Acked-by: Ira Weiny <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
5 years agonet: phy: handle state correctly in phy_stop_machine
Nathan Sullivan [Wed, 22 Mar 2017 20:27:01 +0000 (15:27 -0500)]
net: phy: handle state correctly in phy_stop_machine

commit 49d52e8108a21749dc2114b924c907db43358984 upstream.

If the PHY is halted on stop, then do not set the state to PHY_UP.  This
ensures the phy will be restarted later in phy_start when the machine is
started again.

Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
Signed-off-by: Nathan Sullivan <>
Signed-off-by: Brad Mouring <>
Acked-by: Xander Huff <>
Acked-by: Kyle Roeschley <>
Reviewed-by: Florian Fainelli <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoALSA: seq: Fix race during FIFO resize
Takashi Iwai [Fri, 24 Mar 2017 16:07:57 +0000 (17:07 +0100)]
ALSA: seq: Fix race during FIFO resize

commit 2d7d54002e396c180db0c800c1046f0a3c471597 upstream.

When a new event is queued while processing to resize the FIFO in
snd_seq_fifo_clear(), it may lead to a use-after-free, as the old pool
that is being queued gets removed.  For avoiding this race, we need to
close the pool to be deleted and sync its usage before actually
deleting it.

The issue was spotted by syzkaller.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
5 years agohwmon: (asus_atk0110) fix uninitialized data access
Arnd Bergmann [Thu, 23 Mar 2017 15:03:11 +0000 (16:03 +0100)]
hwmon: (asus_atk0110) fix uninitialized data access

commit a2125d02443e9a4e68bcfd9f8004fa23239e8329 upstream.

The latest gcc-7 snapshot adds a warning to point out that when
atk_read_value_old or atk_read_value_new fails, we copy
uninitialized data into sensor->cached_value:

drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Adding an error check avoids this. All versions of the driver
are affected.

Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support")
Signed-off-by: Arnd Bergmann <>
Reviewed-by: Luca Tettamanti <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
5 years agommc: sdhci: Do not disable interrupts while waiting for clock
Adrian Hunter [Mon, 20 Mar 2017 17:50:29 +0000 (19:50 +0200)]
mmc: sdhci: Do not disable interrupts while waiting for clock

commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.

Signed-off-by: Adrian Hunter <>
Signed-off-by: Ulf Hansson <>
Tested-by: Ludovic Desroches <>
Signed-off-by: Ben Hutchings <>
5 years agos390/decompressor: fix initrd corruption caused by bss clear
Marcelo Henrique Cerri [Mon, 13 Mar 2017 15:14:58 +0000 (12:14 -0300)]
s390/decompressor: fix initrd corruption caused by bss clear

commit d82c0d12c92705ef468683c9b7a8298dd61ed191 upstream.

Reorder the operations in decompress_kernel() to ensure initrd is moved
to a safe location before the bss section is zeroed.

During decompression bss can overlap with the initrd and this can
corrupt the initrd contents depending on the size of the compressed
kernel (which affects where the initrd is placed by the bootloader) and
the size of the bss section of the decompressor.

Also use the correct initrd size when checking for overlaps with

Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
Reviewed-by: Joy Latten <>
Reviewed-by: Vineetha HariPai <>
Signed-off-by: Marcelo Henrique Cerri <>
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Ben Hutchings <>
5 years agosch_dsmark: fix invalid skb_cow() usage
Eric Dumazet [Fri, 17 Mar 2017 15:05:28 +0000 (08:05 -0700)]
sch_dsmark: fix invalid skb_cow() usage

commit aea92fb2e09e29653b023d4254ac9fbf94221538 upstream.

skb_cow(skb, sizeof(ip header)) is not very helpful in this context.

First we need to use pskb_may_pull() to make sure the ip header
is in skb linear part, then use skb_try_make_writable() to
address clones issues.

Fixes: 4c30719f4f55 ("[PKT_SCHED] dsmark: handle cloned and non-linear skb's")
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agobpf: try harder on clones when writing into skb
Daniel Borkmann [Fri, 19 Feb 2016 22:05:25 +0000 (23:05 +0100)]
bpf: try harder on clones when writing into skb

commit 3697649ff29e0f647565eed04b27a7779c646a22 upstream.

When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().

Reported-by: Ashhad Sheikh <>
Signed-off-by: Daniel Borkmann <>
Acked-by: Alexei Starovoitov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: drop changes to bpf; only tc actions need fixing]
Signed-off-by: Ben Hutchings <>
5 years agonet: unix: properly re-increment inflight counter of GC discarded candidates
Andrey Ulanov [Wed, 15 Mar 2017 03:16:42 +0000 (20:16 -0700)]
net: unix: properly re-increment inflight counter of GC discarded candidates

commit 7df9c24625b9981779afb8fcdbe2bb4765e61147 upstream.

Dmitry has reported that a BUG_ON() condition in unix_notinflight()
may be triggered by a simple code that forwards unix socket in an
SCM_RIGHTS message.
That is caused by incorrect unix socket GC implementation in unix_gc().

The GC first collects list of candidates, then (a) decrements their
"children's" inflight counter, (b) checks which inflight counters are
now 0, and then (c) increments all inflight counters back.
(a) and (c) are done by calling scan_children() with inc_inflight or
dec_inflight as the second argument.

Commit 6209344f5a37 ("net: unix: fix inflight counting bug in garbage
collector") changed scan_children() such that it no longer considers
sockets that do not have UNIX_GC_CANDIDATE flag. It also added a block
of code that that unsets this flag _before_ invoking
scan_children(, dec_iflight, ). This may lead to incorrect inflight
counters for some sockets.

This change fixes this bug by changing order of operations:
UNIX_GC_CANDIDATE is now unset only after all inflight counters are
restored to the original state.

  kernel BUG at net/unix/garbage.c:149!
  RIP: 0010:[<ffffffff8717ebf4>]  [<ffffffff8717ebf4>]
  unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
  Call Trace:
   [<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
   [<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
   [<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
   [<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
   [<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
   [<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
   [<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
   [<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
   [<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
   [<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
   [<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
   [<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
   [<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
   [<     inline     >] exit_task_work include/linux/task_work.h:21
   [<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
   [<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
   [<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
   [<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
   [<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
   [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
   [<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
   [<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6

Signed-off-by: Andrey Ulanov <>
Reported-by: Dmitry Vyukov <>
Fixes: 6209344 ("net: unix: fix inflight counting bug in garbage collector")
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoALSA: seq: Fix racy cell insertions during snd_seq_pool_done()
Takashi Iwai [Tue, 21 Mar 2017 12:56:04 +0000 (13:56 +0100)]
ALSA: seq: Fix racy cell insertions during snd_seq_pool_done()

commit c520ff3d03f0b5db7146d9beed6373ad5d2a5e0e upstream.

When snd_seq_pool_done() is called, it marks the closing flag to
refuse the further cell insertions.  But snd_seq_pool_done() itself
doesn't clear the cells but just waits until all cells are cleared by
the caller side.  That is, it's racy, and this leads to the endless
stall as syzkaller spotted.

This patch addresses the racy by splitting the setup of pool->closing
flag out of snd_seq_pool_done(), and calling it properly before

Reported-and-tested-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
5 years agoscsi: libsas: fix ata xfer length
John Garry [Thu, 16 Mar 2017 15:07:28 +0000 (23:07 +0800)]
scsi: libsas: fix ata xfer length

commit 9702c67c6066f583b629cf037d2056245bb7a8e6 upstream.

The total ata xfer length may not be calculated properly, in that we do
not use the proper method to get an sg element dma length.

According to the code comment, sg_dma_len() should be used after
dma_map_sg() is called.

This issue was found by turning on the SMMUv3 in front of the hisi_sas
controller in hip07. Multiple sg elements were being combined into a
single element, but the original first element length was being use as
the total xfer length.

Fixes: ff2aeb1eb64c8a4770a6 ("libata: convert to chained sg")
Signed-off-by: John Garry <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
5 years agoALSA: ctxfi: Fix the incorrect check of dma_set_mask() call
Takashi Iwai [Mon, 20 Mar 2017 09:08:19 +0000 (10:08 +0100)]
ALSA: ctxfi: Fix the incorrect check of dma_set_mask() call

commit f363a06642f28caaa78cb6446bbad90c73fe183c upstream.

In the commit [15c75b09f8d1: ALSA: ctxfi: Fallback DMA mask to 32bit],
I forgot to put "!" at dam_set_mask() call check in cthw20k1.c (while
cthw20k2.c is OK).  This patch fixes that obvious bug.

(As a side note: although the original commit was completely wrong,
 it's still working for most of machines, as it sets to 32bit DMA mask
 in the end.  So the bug severity is low.)

Fixes: 15c75b09f8d1 ("ALSA: ctxfi: Fallback DMA mask to 32bit")
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
5 years agoperf symbols: Fix symbols__fixup_end heuristic for corner cases
Daniel Borkmann [Wed, 15 Mar 2017 21:53:37 +0000 (22:53 +0100)]
perf symbols: Fix symbols__fixup_end heuristic for corner cases

commit e7ede72a6d40cb3a30c087142d79381ca8a31dab upstream.

The current symbols__fixup_end() heuristic for the last entry in the rb
tree is suboptimal as it leads to not being able to recognize the symbol
in the call graph in a couple of corner cases, for example:

 i) If the symbol has a start address (f.e. exposed via kallsyms)
    that is at a page boundary, then the roundup(curr->start, 4096)
    for the last entry will result in curr->start == curr->end with
    a symbol length of zero.

ii) If the symbol has a start address that is shortly before a page
    boundary, then also here, curr->end - curr->start will just be
    very few bytes, where it's unrealistic that we could perform a
    match against.

Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so
that we can catch such corner cases and have a better chance to find
that specific symbol. It's still just best effort as the real end of the
symbol is unknown to us (and could even be at a larger offset than the
current range), but better than the current situation.

Alexei reported that he recently run into case i) with a JITed eBPF
program (these are all page aligned) as the last symbol which wasn't
properly shown in the call graph (while other eBPF program symbols in
the rb tree were displayed correctly). Since this is a generic issue,
lets try to improve the heuristic a bit.

Reported-and-Tested-by: Alexei Starovoitov <>
Signed-off-by: Daniel Borkmann <>
Fixes: 2e538c4a1847 ("perf tools: Improve kernel/modules symbol lookup")
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Ben Hutchings <>
5 years agoACM gadget: fix endianness in notifications
Oliver Neukum [Tue, 14 Mar 2017 11:09:56 +0000 (12:09 +0100)]
ACM gadget: fix endianness in notifications

commit cdd7928df0d2efaa3270d711963773a08a4cc8ab upstream.

The gadget code exports the bitfield for serial status changes
over the wire in its internal endianness. The fix is to convert
to little endian before sending it over the wire.

Signed-off-by: Oliver Neukum <>
Tested-by: 家瑋 <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: usbtmc: add missing endpoint sanity check
Johan Hovold [Tue, 14 Mar 2017 16:55:45 +0000 (17:55 +0100)]
USB: usbtmc: add missing endpoint sanity check

commit 687e0687f71ec00e0132a21fef802dee88c2f1ad upstream.

USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
but the driver failed to verify this, something which could lead to the
endpoint addresses being taken from uninitialised memory.

Make sure to zero all private data as part of allocation, and add the
missing endpoint sanity check.

Note that this also addresses a more recently introduced issue, where
the interrupt-in-presence flag would also be uninitialised whenever the
optional interrupt-in endpoint is not present. This in turn could lead
to an interrupt urb being allocated, initialised and submitted based on
uninitialised values.

Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
Fixes: 5b775f672cc9 ("USB: add USB test and measurement class driver")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agonet: ipv6: set route type for anycast routes
David Ahern [Thu, 16 Mar 2017 01:14:33 +0000 (18:14 -0700)]
net: ipv6: set route type for anycast routes

commit 4ee39733fbecf04cf9f346de2d64788c35028079 upstream.

Anycast routes have the RTF_ANYCAST flag set, but when dumping routes
for userspace the route type is not set to RTN_ANYCAST. Make it so.

Fixes: 58c4fb86eabcb ("[IPV6]: Flag RTF_ANYCAST for anycast routes")
CC: Hideaki YOSHIFUJI <>
Signed-off-by: David Ahern <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoInput: kbtab - validate number of endpoints before using them
Johan Hovold [Thu, 16 Mar 2017 18:41:55 +0000 (11:41 -0700)]
Input: kbtab - validate number of endpoints before using them

commit cb1b494663e037253337623bf1ef2df727883cb7 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Signed-off-by: Johan Hovold <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agoInput: hanwang - validate number of endpoints before using them
Johan Hovold [Thu, 16 Mar 2017 18:39:29 +0000 (11:39 -0700)]
Input: hanwang - validate number of endpoints before using them

commit ba340d7b83703768ce566f53f857543359aa1b98 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets")
Signed-off-by: Johan Hovold <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agoInput: yealink - validate number of endpoints before using them
Johan Hovold [Thu, 16 Mar 2017 18:37:01 +0000 (11:37 -0700)]
Input: yealink - validate number of endpoints before using them

commit 5cc4a1a9f5c179795c8a1f2b0f4361829d6a070e upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone")
Signed-off-by: Johan Hovold <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agoInput: cm109 - validate number of endpoints before using them
Johan Hovold [Thu, 16 Mar 2017 18:35:12 +0000 (11:35 -0700)]
Input: cm109 - validate number of endpoints before using them

commit ac2ee9ba953afe88f7a673e1c0c839227b1d7891 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109...")
Signed-off-by: Johan Hovold <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agoInput: iforce - validate number of endpoints before using them
Johan Hovold [Thu, 16 Mar 2017 18:34:02 +0000 (11:34 -0700)]
Input: iforce - validate number of endpoints before using them

commit 59cf8bed44a79ec42303151dd014fdb6434254bb upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory that lie beyond the end of the endpoint
array should a malicious device lack the expected endpoints.

Signed-off-by: Johan Hovold <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agommc: ushc: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:40:22 +0000 (13:40 +0100)]
mmc: ushc: fix NULL-deref at probe

commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
Cc: David Vrabel <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ulf Hansson <>
Signed-off-by: Ben Hutchings <>
5 years agoperf/core: Fix event inheritance on fork()
Peter Zijlstra [Thu, 16 Mar 2017 12:47:49 +0000 (13:47 +0100)]
perf/core: Fix event inheritance on fork()

commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 upstream.

While hunting for clues to a use-after-free, Oleg spotted that
perf_event_init_context() can loose an error value with the result
that fork() can succeed even though we did not fully inherit the perf
event context.

Spotted-by: Oleg Nesterov <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Alexander Shishkin <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Dmitry Vyukov <>
Cc: Frederic Weisbecker <>
Cc: Jiri Olsa <>
Cc: Linus Torvalds <>
Cc: Mathieu Desnoyers <>
Cc: Peter Zijlstra <>
Cc: Stephane Eranian <>
Cc: Thomas Gleixner <>
Cc: Vince Weaver <>
Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists")
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
5 years agosched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting
Matt Fleming [Fri, 17 Feb 2017 12:07:30 +0000 (12:07 +0000)]
sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

commit 6e5f32f7a43f45ee55c401c0b9585eb01f9629a8 upstream.

If we crossed a sample window while in NO_HZ we will add LOAD_FREQ to
the pending sample window time on exit, setting the next update not
one window into the future, but two.

This situation on exiting NO_HZ is described by:

  this_rq->calc_load_update < jiffies < calc_load_update

In this scenario, what we should be doing is:

  this_rq->calc_load_update = calc_load_update      [ next window ]

But what we actually do is:

  this_rq->calc_load_update = calc_load_update + LOAD_FREQ   [ next+1 window ]

This has the effect of delaying load average updates for potentially
up to ~9seconds.

This can result in huge spikes in the load average values due to
per-cpu uninterruptible task counts being out of sync when accumulated
across all CPUs.

It's safe to update the per-cpu active count if we wake between sample
windows because any load that we left in 'calc_load_idle' will have
been zero'd when the idle load was folded in calc_global_load().

This issue is easy to reproduce before,

  commit 9d89c257dfb9 ("sched/fair: Rewrite runnable load and utilization average tracking")

just by forking short-lived process pipelines built from ps(1) and
grep(1) in a loop. I'm unable to reproduce the spikes after that
commit, but the bug still seems to be present from code review.

Signed-off-by: Matt Fleming <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Frederic Weisbecker <>
Cc: Linus Torvalds <>
Cc: Mike Galbraith <>
Cc: Mike Galbraith <>
Cc: Morten Rasmussen <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Vincent Guittot <>
Fixes: commit 5167e8d ("sched/nohz: Rewrite and fix load-avg computation -- again")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agofutex: Add missing error handling to FUTEX_REQUEUE_PI
Peter Zijlstra [Sat, 4 Mar 2017 09:27:19 +0000 (10:27 +0100)]
futex: Add missing error handling to FUTEX_REQUEUE_PI

commit 9bbb25afeb182502ca4f2c4f3f88af0681b34cae upstream.

Thomas spotted that fixup_pi_state_owner() can return errors and we
fail to unlock the rt_mutex in that case.

Reported-by: Thomas Gleixner <>
Signed-off-by: Peter Zijlstra (Intel) <>
Reviewed-by: Darren Hart <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
5 years agofutex: Fix potential use-after-free in FUTEX_REQUEUE_PI
Peter Zijlstra [Sat, 4 Mar 2017 09:27:18 +0000 (10:27 +0100)]
futex: Fix potential use-after-free in FUTEX_REQUEUE_PI

commit c236c8e95a3d395b0494e7108f0d41cf36ec107c upstream.

While working on the futex code, I stumbled over this potential
use-after-free scenario. Dmitry triggered it later with syzkaller.

pi_mutex is a pointer into pi_state, which we drop the reference on in
unqueue_me_pi(). So any access to that pointer after that is bad.

Since other sites already do rt_mutex_unlock() with hb->lock held, see
for example futex_lock_pi(), simply move the unlock before

Reported-by: Dmitry Vyukov <>
Signed-off-by: Peter Zijlstra (Intel) <>
Reviewed-by: Darren Hart <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
5 years agoUSB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems
Dan Williams [Thu, 9 Mar 2017 17:32:28 +0000 (11:32 -0600)]
USB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems

commit 6e9f44eaaef0df7b846e9316fa9ca72a02025d44 upstream.

Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
qcserial due to a USB VID/PID conflict with an existing Acer

Signed-off-by: Dan Williams <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
5 years agousb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk
Samuel Thibault [Mon, 13 Mar 2017 19:50:08 +0000 (20:50 +0100)]

commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agouwb: i1480-dfu: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:47:53 +0000 (13:47 +0100)]
uwb: i1480-dfu: fix NULL-deref at probe

commit 4ce362711d78a4999011add3115b8f4b0bc25e8c upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Note that the dereference happens in the cmd and wait_init_done
callbacks which are called during probe.

Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
Cc: Inaky Perez-Gonzalez <>
Cc: David Vrabel <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agouwb: hwa-rc: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:47:52 +0000 (13:47 +0100)]
uwb: hwa-rc: fix NULL-deref at probe

commit daf229b15907fbfdb6ee183aac8ca428cb57e361 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Note that the dereference happens in the start callback which is called
during probe.

Fixes: de520b8bd552 ("uwb: add HWA radio controller driver")
Cc: Inaky Perez-Gonzalez <>
Cc: David Vrabel <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agoUSB: wusbcore: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:47:51 +0000 (13:47 +0100)]
USB: wusbcore: fix NULL-deref at probe

commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

This specifically fixes the NULL-pointer dereference when probing HWA HC

Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
Cc: Inaky Perez-Gonzalez <>
Cc: David Vrabel <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agoUSB: uss720: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:47:50 +0000 (13:47 +0100)]
USB: uss720: fix NULL-deref at probe

commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Note that the endpoint access that causes the NULL-deref is currently
only used for debugging purposes during probe so the oops only happens
when dynamic debugging is enabled. This means the driver could be
rewritten to continue to accept device with only two endpoints, should
such devices exist.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agoUSB: idmouse: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:47:48 +0000 (13:47 +0100)]
USB: idmouse: fix NULL-deref at probe

commit b0addd3fa6bcd119be9428996d5d4522479ab240 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agonet: wimax/i2400m: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:42:03 +0000 (13:42 +0100)]
net: wimax/i2400m: fix NULL-deref at probe

commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

The endpoints are specifically dereferenced in the i2400m_bootrom_init
path during probe (e.g. in i2400mu_tx_bulk_out).

Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown
and reset backends")
Cc: Inaky Perez-Gonzalez <>
Signed-off-by: Johan Hovold <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoisdn/gigaset: fix NULL-deref at probe
Johan Hovold [Mon, 13 Mar 2017 12:39:01 +0000 (13:39 +0100)]
isdn/gigaset: fix NULL-deref at probe

commit 68c32f9c2a36d410aa242e661506e5b2c2764179 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers -
direct USB connection")
Cc: Hansjoerg Lipp <>
Signed-off-by: Johan Hovold <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoudp: avoid ufo handling on IP payload compression packets
Alexey Kodanev [Thu, 9 Mar 2017 10:56:46 +0000 (13:56 +0300)]
udp: avoid ufo handling on IP payload compression packets

commit 4b3b45edba9222e518a1ec72df841eba3609fe34 upstream.

commit c146066ab802 ("ipv4: Don't use ufo handling on later transformed
packets") and commit f89c56ce710a ("ipv6: Don't use ufo handling on
later transformed packets") added a check that 'rt->dst.header_len' isn't
zero in order to skip UFO, but it doesn't include IPcomp in transport mode
where it equals zero.

Packets, after payload compression, may not require further fragmentation,
and if original length exceeds MTU, later compressed packets will be
transmitted incorrectly. This can be reproduced with LTP test
on veth device with enabled UFO, MTU is 1500 and UDP payload is 2000:

* IPv4 case, offset is wrong + unnecessary fragmentation -p comp -m transport -s 2000 &
    tcpdump -ni ltp_ns_veth2
    IP (tos 0x0, ttl 64, id 45203, offset 0, flags [+],
      proto Compressed IP (108), length 49) > IPComp(cpi=0x1000)
    IP (tos 0x0, ttl 64, id 45203, offset 1480, flags [none],
      proto UDP (17), length 21) > ip-proto-17

* IPv6 case, sending small fragments -6 -p comp -m transport -s 2000 &
    tcpdump -ni ltp_ns_veth2
    IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108)
      payload length: 37) fd00::2 > fd00::1: IPComp(cpi=0x1000)
    IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108)
      payload length: 21) fd00::2 > fd00::1: IPComp(cpi=0x1000)

Fix it by checking 'rt->dst.xfrm' pointer to 'xfrm_state' struct, skip UFO
if xfrm is set. So the new check will include both cases: IPcomp and IPsec.

Fixes: c146066ab802 ("ipv4: Don't use ufo handling on later transformed packets")
Fixes: f89c56ce710a ("ipv6: Don't use ufo handling on later transformed packets")
Signed-off-by: Alexey Kodanev <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: iowarrior: fix NULL-deref in write
Johan Hovold [Tue, 7 Mar 2017 15:11:04 +0000 (16:11 +0100)]
USB: iowarrior: fix NULL-deref in write

commit de46e56653de7b3b54baa625bd582635008b8d05 upstream.

Make sure to verify that we have the required interrupt-out endpoint for
IOWarrior56 devices to avoid dereferencing a NULL-pointer in write
should a malicious device lack such an endpoint.

Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agodvb-usb-firmware: don't do DMA on stack
Stefan Brüns [Sun, 12 Feb 2017 15:02:13 +0000 (13:02 -0200)]
dvb-usb-firmware: don't do DMA on stack

commit 67b0503db9c29b04eadfeede6bebbfe5ddad94ef upstream.

The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
but the same applies for the reset value.

Fixes: 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
Signed-off-by: Stefan Brüns <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agodvb-usb: don't use stack for firmware load
Mauro Carvalho Chehab [Tue, 24 Jan 2017 10:13:11 +0000 (08:13 -0200)]
dvb-usb: don't use stack for firmware load

commit 43fab9793c1f44e665b4f98035a14942edf03ddc upstream.

As reported by Marc Duponcheel <>, firmware load on
dvb-usb is using the stack, with is not allowed anymore on default
Kernel configurations:

[ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
[ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[ 1025.958855] dvb-usb: could not stop the USB controller CPU.
[ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
[ 1025.958856] dvb-usb: firmware download failed at 8 with -22
[ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u

[    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[    2.789905] ------------[ cut here ]------------
[    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789912] transfer buffer not dma capable
[    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
[    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
[    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
[    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
[    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
[    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
[    2.789942] Call Trace:
[    2.789945]  [<ffffffff812bd397>] dump_stack+0x4d/0x66
[    2.789947]  [<ffffffff81055c86>] __warn+0xc6/0xe0
[    2.789948]  [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50
[    2.789952]  [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789954]  [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110
[    2.789956]  [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
[    2.789958]  [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0
[    2.789960]  [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240
[    2.789962]  [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0
[    2.789964]  [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore]
[    2.789967]  [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[    2.789969]  [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore]
[    2.789970]  [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
[    2.789972]  [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
[    2.789973]  [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0
[    2.789974]  [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410
[    2.789975]  [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20
[    2.789976]  [<ffffffff81124d76>] ? printk+0x43/0x4b
[    2.789977]  [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
[    2.789979]  [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
[    2.789981]  [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
[    2.789984]  [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore]
[    2.789985]  [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0
[    2.789986]  [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0
[    2.789987]  [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0
[    2.789988]  [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90
[    2.789989]  [<ffffffff8138b7b9>] driver_attach+0x19/0x20
[    2.789990]  [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220
[    2.789991]  [<ffffffff8138c91b>] driver_register+0x5b/0xd0
[    2.789994]  [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore]
[    2.789994]  [<ffffffffa06a5000>] ? 0xffffffffa06a5000
[    2.789996]  [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
[    2.789997]  [<ffffffff81000408>] do_one_initcall+0x38/0x140
[    2.789998]  [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0
[    2.789999]  [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2
[    2.790000]  [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2
[    2.790002]  [<ffffffff810c96b1>] load_module+0x1e11/0x2580
[    2.790003]  [<ffffffff810c68b0>] ? show_taint+0x30/0x30
[    2.790004]  [<ffffffff81177250>] ? kernel_read_file+0x100/0x190
[    2.790005]  [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0
[    2.790007]  [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94
[    2.790008] ---[ end trace c78a74e78baec6fc ]---

So, allocate the structure dynamically.

Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: serial: safe_serial: fix information leak in completion handler
Johan Hovold [Mon, 6 Mar 2017 16:36:41 +0000 (17:36 +0100)]
USB: serial: safe_serial: fix information leak in completion handler

commit 8c76d7cd520ebffc1ea9ea0850d87a224a50c7f2 upstream.

Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that could be triggered by a malicious device.

This avoids leaking up to 56 bytes from after the URB transfer buffer to
user space.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
5 years agoUSB: serial: io_ti: fix NULL-deref in interrupt callback
Johan Hovold [Mon, 6 Mar 2017 16:36:37 +0000 (17:36 +0100)]
USB: serial: io_ti: fix NULL-deref in interrupt callback

commit 0b1d250afb8eb9d65afb568bac9b9f9253a82b49 upstream.

Fix a NULL-pointer dereference in the interrupt callback should a
malicious device send data containing a bad port number by adding the
missing sanity check.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2:
 - Use &urb->dev->dev instead of local dev variable
 - Adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoscsi: lpfc: Add shutdown method for kexec
Anton Blanchard [Sun, 12 Feb 2017 21:49:20 +0000 (08:49 +1100)]
scsi: lpfc: Add shutdown method for kexec

commit 85e8a23936ab3442de0c42da97d53b29f004ece1 upstream.

We see lpfc devices regularly fail during kexec. Fix this by adding a
shutdown method which mirrors the remove method.

Signed-off-by: Anton Blanchard <>
Reviewed-by: Mauricio Faria de Oliveira <>
Tested-by: Mauricio Faria de Oliveira <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoInput: i8042 - add noloop quirk for Dell Embedded Box PC 3000
Kai-Heng Feng [Tue, 7 Mar 2017 17:31:29 +0000 (09:31 -0800)]
Input: i8042 - add noloop quirk for Dell Embedded Box PC 3000

commit 45838660e34d90db8d4f7cbc8fd66e8aff79f4fe upstream.

The aux port does not get detected without noloop quirk, so external PS/2
mouse cannot work as result.

The PS/2 mouse can work with this quirk.

Signed-off-by: Kai-Heng Feng <>
Reviewed-by: Marcos Paulo de Souza <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agoscsi: aacraid: Fix typo in blink status
Raghava Aditya Renukunta [Thu, 2 Mar 2017 17:21:33 +0000 (09:21 -0800)]
scsi: aacraid: Fix typo in blink status

commit 934767c56b0d9dbb95a40e9e6e4d9dcdc3a165ad upstream.

The return status of the adapter check on KERNEL_PANIC is supposed to be
the upper 16 bits of the OMR status register.

Fixes: c421530bf848604e (scsi: aacraid: Reorder Adpater status check)
Reported-by: Dan Carpenter <>
Signed-off-by: Raghava Aditya Renukunta <>
Reviewed-by: Dave Carroll <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
5 years agousb: dwc3: gadget: make Set Endpoint Configuration macros safe
Felipe Balbi [Tue, 31 Jan 2017 11:24:54 +0000 (13:24 +0200)]
usb: dwc3: gadget: make Set Endpoint Configuration macros safe

commit 7369090a9fb57c3fc705ce355d2e4523a5a24716 upstream.

Some gadget drivers are bad, bad boys. We notice
that ADB was passing bad Burst Size which caused top
bits of param0 to be overwritten which confused DWC3
when running this command.

In order to avoid future issues, we're going to make
sure values passed by macros are always safe for the
controller. Note that ADB still needs a fix to *not*
pass bad values.

Reported-by: Mohamed Abbas <>
Sugested-by: Adam Andruszak <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
5 years agotracing: Add #undef to fix compile error
Rik van Riel [Thu, 29 Sep 2016 02:55:54 +0000 (22:55 -0400)]
tracing: Add #undef to fix compile error

commit bf7165cfa23695c51998231c4efa080fe1d3548d upstream.

There are several trace include files that define TRACE_INCLUDE_FILE.

Include several of them in the same .c file (as I currently have in
some code I am working on), and the compile will blow up with a
"warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls"

Every other include file in include/trace/events/ avoids that issue
by having a #undef TRACE_INCLUDE_FILE before the #define; syscalls.h
should have one, too.

Fixes: b8007ef74222 ("tracing: Separate raw syscall from syscall tracer")
Signed-off-by: Rik van Riel <>
Signed-off-by: Steven Rostedt (VMware) <>
Signed-off-by: Ben Hutchings <>
5 years agoxen: do not re-use pirq number cached in pci device msi msg data
Dan Streetman [Fri, 13 Jan 2017 20:07:51 +0000 (15:07 -0500)]
xen: do not re-use pirq number cached in pci device msi msg data

commit c74fd80f2f41d05f350bb478151021f88551afe8 upstream.

Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")

That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq.  At the time, that was the correct behavior.  However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
("qemu-xen: free all the pirqs for msi/msix when driver unload")

Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.

This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs.  So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.

This is discussed in more detail at:

Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
Signed-off-by: Dan Streetman <>
Reviewed-by: Stefano Stabellini <>
Acked-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Boris Ostrovsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoLinux 3.2.90 v3.2.90
Ben Hutchings [Sun, 2 Jul 2017 16:12:48 +0000 (17:12 +0100)]
Linux 3.2.90

5 years agomm: fix find_vma_prev
Mikulas Patocka [Mon, 5 Mar 2012 00:52:03 +0000 (19:52 -0500)]
mm: fix find_vma_prev

commit 83cd904d271ba960c53f3adbb037f3486518f1e6 upstream.

Commit 6bd4837de96e ("mm: simplify find_vma_prev()") broke memory
management on PA-RISC.

After application of the patch, programs that allocate big arrays on the
stack crash with segfault, for example, this will crash if compiled
without optimization:

  int main()
char array[200000];
array[199999] = 0;
return 0;

The reason is that PA-RISC has up-growing stack and the stack is usually
the last memory area.  In the above example, a page fault happens above
the stack.

Previously, if we passed too high address to find_vma_prev, it returned
NULL and stored the last VMA in *pprev.  After "simplify find_vma_prev"
change, it stores NULL in *pprev.  Consequently, the stack area is not
found and it is not expanded, as it used to be before the change.

This patch restores the old behavior and makes it return the last VMA in
*pprev if the requested address is higher than address of any other VMA.

Signed-off-by: Mikulas Patocka <>
Acked-by: KOSAKI Motohiro <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agomm: simplify find_vma_prev()
KOSAKI Motohiro [Tue, 10 Jan 2012 23:08:07 +0000 (15:08 -0800)]
mm: simplify find_vma_prev()

commit 6bd4837de96e7d9f9bf33e59117c24fc230862ac upstream.

commit 297c5eee37 ("mm: make the vma list be doubly linked") added the
vm_prev member to vm_area_struct.  We can simplify find_vma_prev() by
using it.  Also, this change helps to improve page fault performance
because it has stronger locality of reference.

Signed-off-by: KOSAKI Motohiro <>
Reviewed-by: KAMEZAWA Hiroyuki <>
Cc: Hugh Dickins <>
Cc: Peter Zijlstra <>
Cc: Shaohua Li <>
Cc: Michal Hocko <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agorxrpc: Fix several cases where a padded len isn't checked in ticket decode
David Howells [Wed, 14 Jun 2017 23:12:24 +0000 (00:12 +0100)]
rxrpc: Fix several cases where a padded len isn't checked in ticket decode

commit 5f2f97656ada8d811d3c1bef503ced266fcd53a0 upstream.

This fixes CVE-2017-7482.

When a kerberos 5 ticket is being decoded so that it can be loaded into an
rxrpc-type key, there are several places in which the length of a
variable-length field is checked to make sure that it's not going to
overrun the available data - but the data is padded to the nearest
four-byte boundary and the code doesn't check for this extra.  This could
lead to the size-remaining variable wrapping and the data pointer going
over the end of the buffer.

Fix this by making the various variable-length data checks use the padded

Reported-by: 石磊 <>
Signed-off-by: David Howells <>
Reviewed-by: Marc Dionne <>
Reviewed-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
5 years agoAllow stack to grow up to address space limit
Helge Deller [Mon, 19 Jun 2017 15:34:05 +0000 (17:34 +0200)]
Allow stack to grow up to address space limit

commit bd726c90b6b8ce87602208701b208a208e6d5600 upstream.

Fix expand_upwards() on architectures with an upward-growing stack (parisc,
metag and partly IA-64) to allow the stack to reliably grow exactly up to
the address space limit given by TASK_SIZE.

Signed-off-by: Helge Deller <>
Acked-by: Hugh Dickins <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agomm: larger stack guard gap, between vmas
Hugh Dickins [Mon, 19 Jun 2017 18:32:47 +0000 (20:32 +0200)]
mm: larger stack guard gap, between vmas

commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov <>
Original-patch-by: Michal Hocko <>
Signed-off-by: Hugh Dickins <>
Acked-by: Michal Hocko <>
Tested-by: Helge Deller <> # parisc
Signed-off-by: Linus Torvalds <>
[Hugh Dickins: Backported to 3.2]
[bwh: Fix more instances of vma->vm_start in sparc64 impl. of
 arch_get_unmapped_area_topdown() and generic impl. of
Signed-off-by: Ben Hutchings <>
5 years agomm: do not grow the stack vma just because of an overrun on preceding vma
Linus Torvalds [Wed, 27 Feb 2013 16:36:04 +0000 (08:36 -0800)]
mm: do not grow the stack vma just because of an overrun on preceding vma

commit 09884964335e85e897876d17783c2ad33cf8a2e0 upstream.

The stack vma is designed to grow automatically (marked with VM_GROWSUP
or VM_GROWSDOWN depending on architecture) when an access is made beyond
the existing boundary.  However, particularly if you have not limited
your stack at all ("ulimit -s unlimited"), this can cause the stack to
grow even if the access was really just one past *another* segment.

And that's wrong, especially since we first grow the segment, but then
immediately later enforce the stack guard page on the last page of the
segment.  So _despite_ first growing the stack segment as a result of
the access, the kernel will then make the access cause a SIGSEGV anyway!

So do the same logic as the guard page check does, and consider an
access to within one page of the next segment to be a bad access, rather
than growing the stack to abut the next segment.

Reported-and-tested-by: Heiko Carstens <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agoLinux 3.2.89 v3.2.89
Ben Hutchings [Mon, 5 Jun 2017 20:13:58 +0000 (21:13 +0100)]
Linux 3.2.89

5 years agoipv6: fix out of bound writes in __ip6_append_data()
Eric Dumazet [Fri, 19 May 2017 21:17:48 +0000 (14:17 -0700)]
ipv6: fix out of bound writes in __ip6_append_data()

commit 232cd35d0804cc241eb887bb8d4d9b3b9881c64a upstream.

Andrey Konovalov and reported crashes caused by
one skb shared_info being overwritten from __ip6_append_data()

Andrey program lead to following state :

copy -4200 datalen 2000 fraglen 2040
maxfraglen 2040 alloclen 2048 transhdrlen 0 offset 0 fraggap 6200

The skb_copy_and_csum_bits(skb_prev, maxfraglen, data + transhdrlen,
fraggap, 0); is overwriting skb->head and skb_shared_info

Since we apparently detect this rare condition too late, move the
code earlier to even avoid allocating skb and risking crashes.

Once again, many thanks to Andrey and syzkaller team.

Signed-off-by: Eric Dumazet <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Reported-by: <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoipv6/dccp: do not inherit ipv6_mc_list from parent
WANG Cong [Tue, 9 May 2017 23:59:54 +0000 (16:59 -0700)]
ipv6/dccp: do not inherit ipv6_mc_list from parent

commit 83eaddab4378db256d00d295bda6ca997cd13a52 upstream.

Like commit 657831ffc38e ("dccp/tcp: do not inherit mc_list from parent")
we should clear ipv6_mc_list etc. for IPv6 sockets too.

Cc: Eric Dumazet <>
Signed-off-by: Cong Wang <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agosctp: do not inherit ipv6_{mc|ac|fl}_list from parent
Eric Dumazet [Wed, 17 May 2017 14:16:40 +0000 (07:16 -0700)]
sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

commit fdcee2cbb8438702ea1b328fb6e0ac5e9a40c7f8 upstream.

SCTP needs fixes similar to 83eaddab4378 ("ipv6/dccp: do not inherit
ipv6_mc_list from parent"), otherwise bad things can happen.

Signed-off-by: Eric Dumazet <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoipv6: Check ip6_find_1stfragopt() return value properly.
David S. Miller [Thu, 18 May 2017 02:54:11 +0000 (22:54 -0400)]
ipv6: Check ip6_find_1stfragopt() return value properly.

commit 7dd7eb9513bd02184d45f000ab69d78cb1fa1531 upstream.

Do not use unsigned variables to see if it returns a negative
error or not.

Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Reported-by: Julia Lawall <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filenames, context]
Signed-off-by: Ben Hutchings <>
5 years agoipv6: Prevent overrun when parsing v6 header options
Craig Gallek [Tue, 16 May 2017 18:36:23 +0000 (14:36 -0400)]
ipv6: Prevent overrun when parsing v6 header options

commit 2423496af35d94a87156b063ea5cedffc10a70a1 upstream.

The KASAN warning repoted below was discovered with a syzkaller
program.  The reproducer is basically:
  int s = socket(AF_INET6, SOCK_RAW, NEXTHDR_HOP);
  send(s, &one_byte_of_data, 1, MSG_MORE);
  send(s, &more_than_mtu_bytes_data, 2000, 0);

The socket() call sets the nexthdr field of the v6 header to
NEXTHDR_HOP, the first send call primes the payload with a non zero
byte of data, and the second send call triggers the fragmentation path.

The fragmentation code tries to parse the header options in order
to figure out where to insert the fragment option.  Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of the skb and data
is read outside of it.

This fix makes ip6_find_1stfrag return an error if it detects
running out-of-bounds.

[   42.361487] ==================================================================
[   42.364412] BUG: KASAN: slab-out-of-bounds in ip6_fragment+0x11c8/0x3730
[   42.365471] Read of size 840 at addr ffff88000969e798 by task ip6_fragment-oo/3789
[   42.366469]
[   42.366696] CPU: 1 PID: 3789 Comm: ip6_fragment-oo Not tainted 4.11.0+ #41
[   42.367628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
[   42.368824] Call Trace:
[   42.369183]  dump_stack+0xb3/0x10b
[   42.369664]  print_address_description+0x73/0x290
[   42.370325]  kasan_report+0x252/0x370
[   42.370839]  ? ip6_fragment+0x11c8/0x3730
[   42.371396]  check_memory_region+0x13c/0x1a0
[   42.371978]  memcpy+0x23/0x50
[   42.372395]  ip6_fragment+0x11c8/0x3730
[   42.372920]  ? nf_ct_expect_unregister_notifier+0x110/0x110
[   42.373681]  ? ip6_copy_metadata+0x7f0/0x7f0
[   42.374263]  ? ip6_forward+0x2e30/0x2e30
[   42.374803]  ip6_finish_output+0x584/0x990
[   42.375350]  ip6_output+0x1b7/0x690
[   42.375836]  ? ip6_finish_output+0x990/0x990
[   42.376411]  ? ip6_fragment+0x3730/0x3730
[   42.376968]  ip6_local_out+0x95/0x160
[   42.377471]  ip6_send_skb+0xa1/0x330
[   42.377969]  ip6_push_pending_frames+0xb3/0xe0
[   42.378589]  rawv6_sendmsg+0x2051/0x2db0
[   42.379129]  ? rawv6_bind+0x8b0/0x8b0
[   42.379633]  ? _copy_from_user+0x84/0xe0
[   42.380193]  ? debug_check_no_locks_freed+0x290/0x290
[   42.380878]  ? ___sys_sendmsg+0x162/0x930
[   42.381427]  ? rcu_read_lock_sched_held+0xa3/0x120
[   42.382074]  ? sock_has_perm+0x1f6/0x290
[   42.382614]  ? ___sys_sendmsg+0x167/0x930
[   42.383173]  ? lock_downgrade+0x660/0x660
[   42.383727]  inet_sendmsg+0x123/0x500
[   42.384226]  ? inet_sendmsg+0x123/0x500
[   42.384748]  ? inet_recvmsg+0x540/0x540
[   42.385263]  sock_sendmsg+0xca/0x110
[   42.385758]  SYSC_sendto+0x217/0x380
[   42.386249]  ? SYSC_connect+0x310/0x310
[   42.386783]  ? __might_fault+0x110/0x1d0
[   42.387324]  ? lock_downgrade+0x660/0x660
[   42.387880]  ? __fget_light+0xa1/0x1f0
[   42.388403]  ? __fdget+0x18/0x20
[   42.388851]  ? sock_common_setsockopt+0x95/0xd0
[   42.389472]  ? SyS_setsockopt+0x17f/0x260
[   42.390021]  ? entry_SYSCALL_64_fastpath+0x5/0xbe
[   42.390650]  SyS_sendto+0x40/0x50
[   42.391103]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.391731] RIP: 0033:0x7fbbb711e383
[   42.392217] RSP: 002b:00007ffff4d34f28 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[   42.393235] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbbb711e383
[   42.394195] RDX: 0000000000001000 RSI: 00007ffff4d34f60 RDI: 0000000000000003
[   42.395145] RBP: 0000000000000046 R08: 00007ffff4d34f40 R09: 0000000000000018
[   42.396056] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400aad
[   42.396598] R13: 0000000000000066 R14: 00007ffff4d34ee0 R15: 00007fbbb717af00
[   42.397257]
[   42.397411] Allocated by task 3789:
[   42.397702]  save_stack_trace+0x16/0x20
[   42.398005]  save_stack+0x46/0xd0
[   42.398267]  kasan_kmalloc+0xad/0xe0
[   42.398548]  kasan_slab_alloc+0x12/0x20
[   42.398848]  __kmalloc_node_track_caller+0xcb/0x380
[   42.399224]  __kmalloc_reserve.isra.32+0x41/0xe0
[   42.399654]  __alloc_skb+0xf8/0x580
[   42.400003]  sock_wmalloc+0xab/0xf0
[   42.400346]  __ip6_append_data.isra.41+0x2472/0x33d0
[   42.400813]  ip6_append_data+0x1a8/0x2f0
[   42.401122]  rawv6_sendmsg+0x11ee/0x2db0
[   42.401505]  inet_sendmsg+0x123/0x500
[   42.401860]  sock_sendmsg+0xca/0x110
[   42.402209]  ___sys_sendmsg+0x7cb/0x930
[   42.402582]  __sys_sendmsg+0xd9/0x190
[   42.402941]  SyS_sendmsg+0x2d/0x50
[   42.403273]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.403718]
[   42.403871] Freed by task 1794:
[   42.404146]  save_stack_trace+0x16/0x20
[   42.404515]  save_stack+0x46/0xd0
[   42.404827]  kasan_slab_free+0x72/0xc0
[   42.405167]  kfree+0xe8/0x2b0
[   42.405462]  skb_free_head+0x74/0xb0
[   42.405806]  skb_release_data+0x30e/0x3a0
[   42.406198]  skb_release_all+0x4a/0x60
[   42.406563]  consume_skb+0x113/0x2e0
[   42.406910]  skb_free_datagram+0x1a/0xe0
[   42.407288]  netlink_recvmsg+0x60d/0xe40
[   42.407667]  sock_recvmsg+0xd7/0x110
[   42.408022]  ___sys_recvmsg+0x25c/0x580
[   42.408395]  __sys_recvmsg+0xd6/0x190
[   42.408753]  SyS_recvmsg+0x2d/0x50
[   42.409086]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   42.409513]
[   42.409665] The buggy address belongs to the object at ffff88000969e780
[   42.409665]  which belongs to the cache kmalloc-512 of size 512
[   42.410846] The buggy address is located 24 bytes inside of
[   42.410846]  512-byte region [ffff88000969e780ffff88000969e980)
[   42.411941] The buggy address belongs to the page:
[   42.412405] page:ffffea000025a780 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
[   42.413298] flags: 0x100000000008100(slab|head)
[   42.413729] raw: 0100000000008100 0000000000000000 0000000000000000 00000001800c000c
[   42.414387] raw: ffffea00002a9500 0000000900000007 ffff88000c401280 0000000000000000
[   42.415074] page dumped because: kasan: bad access detected
[   42.415604]
[   42.415757] Memory state around the buggy address:
[   42.416222]  ffff88000969e880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   42.416904]  ffff88000969e900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   42.417591] >ffff88000969e980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   42.418273]                    ^
[   42.418588]  ffff88000969ea00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   42.419273]  ffff88000969ea80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   42.419882] ==================================================================

Reported-by: Andrey Konovalov <>
Signed-off-by: Craig Gallek <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filenames, context]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: serial: omninet: fix reference leaks at open
Johan Hovold [Mon, 6 Mar 2017 16:36:38 +0000 (17:36 +0100)]
USB: serial: omninet: fix reference leaks at open

commit 30572418b445d85fcfe6c8fe84c947d2606767d8 upstream.

This driver needlessly took another reference to the tty on open, a
reference which was then never released on close. This lead to not just
a leak of the tty, but also a driver reference leak that prevented the
driver from being unloaded after a port had once been opened.

Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2:
 - The 'serial' variable is still needed for other initialisation
 - Adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: serial: io_ti: fix information leak in completion handler
Johan Hovold [Mon, 6 Mar 2017 16:36:40 +0000 (17:36 +0100)]
USB: serial: io_ti: fix information leak in completion handler

commit 654b404f2a222f918af9b0cd18ad469d0c941a8e upstream.

Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that can be triggered by a malicious device.

This avoids leaking 128 kB of memory content from after the URB transfer
buffer to user space.

Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
5 years agodccp/tcp: do not inherit mc_list from parent
Eric Dumazet [Tue, 9 May 2017 13:29:19 +0000 (06:29 -0700)]
dccp/tcp: do not inherit mc_list from parent

commit 657831ffc38e30092a2d5f03d385d710eb88b09a upstream.

syzkaller found a way to trigger double frees from ip_mc_drop_socket()

It turns out that leave a copy of parent mc_list at accept() time,
which is very bad.

Very similar to commit 8b485ce69876 ("tcp: do not inherit
fastopen_req from parent")

Initial report from Pray3r, completed by Andrey one.
Thanks a lot to them !

Signed-off-by: Eric Dumazet <>
Reported-by: Pray3r <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agonfsd: stricter decoding of write-like NFSv2/v3 ops
J. Bruce Fields [Fri, 21 Apr 2017 19:26:30 +0000 (15:26 -0400)]
nfsd: stricter decoding of write-like NFSv2/v3 ops

commit 13bf9fbff0e5e099e2b6f003a0ab8ae145436309 upstream.

The NFSv2/v3 code does not systematically check whether we decode past
the end of the buffer.  This generally appears to be harmless, but there
are a few places where we do arithmetic on the pointers involved and
don't account for the possibility that a length could be negative.  Add
checks to catch these.

Reported-by: Tuomas Haanpää <>
Reported-by: Ari Kauppi <>
Reviewed-by: NeilBrown <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
5 years agonfsd4: minor NFSv2/v3 write decoding cleanup
J. Bruce Fields [Tue, 25 Apr 2017 20:21:34 +0000 (16:21 -0400)]
nfsd4: minor NFSv2/v3 write decoding cleanup

commit db44bac41bbfc0c0d9dd943092d8bded3c9db19b upstream.

Use a couple shortcuts that will simplify a following bugfix.

Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2: in nfs3svc_decode_writeargs(), dlen doesn't include
Signed-off-by: Ben Hutchings <>
5 years agonfsd: check for oversized NFSv2/v3 arguments
J. Bruce Fields [Fri, 21 Apr 2017 20:10:18 +0000 (16:10 -0400)]
nfsd: check for oversized NFSv2/v3 arguments

commit e6838a29ecb484c97e4efef9429643b9851fba6e upstream.

A client can append random data to the end of an NFSv2 or NFSv3 RPC call
without our complaining; we'll just stop parsing at the end of the
expected data and ignore the rest.

Encoded arguments and replies are stored together in an array of pages,
and if a call is too large it could leave inadequate space for the
reply.  This is normally OK because NFS RPC's typically have either
short arguments and long replies (like READ) or long arguments and short
replies (like WRITE).  But a client that sends an incorrectly long reply
can violate those assumptions.  This was observed to cause crashes.

Also, several operations increment rq_next_page in the decode routine
before checking the argument size, which can leave rq_next_page pointing
well past the end of the page array, causing trouble later in

So, following a suggestion from Neil Brown, add a central check to
enforce our expectation that no NFSv2/v3 call has both a large call and
a large reply.

As followup we may also want to rewrite the encoding routines to check
more carefully that they aren't running off the end of the page array.

We may also consider rejecting calls that have any extra garbage
appended.  That would be safer, and within our rights by spec, but given
the age of our server and the NFS protocol, and the fact that we've
never enforced this before, we may need to balance that against the
possibility of breaking some oddball client.

Reported-by: Tuomas Haanpää <>
Reported-by: Ari Kauppi <>
Reviewed-by: NeilBrown <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
5 years agoipx: call ipxitf_put() in ioctl error path
Dan Carpenter [Tue, 2 May 2017 10:58:53 +0000 (13:58 +0300)]
ipx: call ipxitf_put() in ioctl error path

commit ee0d8d8482345ff97a75a7d747efc309f13b0d80 upstream.

We should call ipxitf_put() if the copy_to_user() fails.

Reported-by: 李强 <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agotracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Amey Telawane [Wed, 3 May 2017 10:11:14 +0000 (15:41 +0530)]
tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

commit e09e28671cda63e6308b31798b997639120e2a21 upstream.

Strcpy is inherently not safe, and strlcpy() should be used instead.
__trace_find_cmdline() uses strcpy() because the comms saved must have a
terminating nul character, but it doesn't hurt to add the extra protection
of using strlcpy() instead of strcpy().

Signed-off-by: Amey Telawane <>
[AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10]
Signed-off-by: Amit Pundir <>
[ Updated change log and removed the "- 1" from len parameter ]
Signed-off-by: Steven Rostedt (VMware) <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agocrypto: ahash - Fix EINPROGRESS notification callback
Herbert Xu [Mon, 10 Apr 2017 09:27:57 +0000 (17:27 +0800)]
crypto: ahash - Fix EINPROGRESS notification callback

commit ef0579b64e93188710d48667cb5e014926af9f1b upstream.

The ahash API modifies the request's callback function in order
to clean up after itself in some corner cases (unaligned final
and missing finup).

When the request is complete ahash will restore the original
callback and everything is fine.  However, when the request gets
an EBUSY on a full queue, an EINPROGRESS callback is made while
the request is still ongoing.

In this case the ahash API will incorrectly call its own callback.

This patch fixes the problem by creating a temporary request
object on the stack which is used to relay EINPROGRESS back to
the original completion function.

This patch also adds code to preserve the original flags value.

Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...")
Reported-by: Sabrina Dubroca <>
Tested-by: Sabrina Dubroca <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
5 years agocrypto: hash - Simplify the ahash_finup implementation
Marek Vasut [Fri, 14 Mar 2014 01:37:06 +0000 (02:37 +0100)]
crypto: hash - Simplify the ahash_finup implementation

commit d4a7a0fbe959e12bdd071b79b50ed34853a6db8f upstream.

The ahash_def_finup() can make use of the request save/restore functions,
thus make it so. This simplifies the code a little and unifies the code

Note that the same remark about free()ing the req->priv applies here, the
req->priv can only be free()'d after the original request was restored.

Finally, squash a bug in the invocation of completion in the ASYNC path.
In both ahash_def_finup_done{1,2}, the function areq->base.complete(X, err);
was called with X=areq-> . This is incorrect , as X=&areq->base
is the correct value. By analysis of the data structures, we see the areq is
of type 'struct ahash_request' , areq->base is of type 'struct crypto_async_request'
and areq->base.completion is of type crypto_completion_t, which is defined in
include/linux/crypto.h as:

  typedef void (*crypto_completion_t)(struct crypto_async_request *req, int err);

This is one lead that the X should be &areq->base . Next up, we can inspect
other code which calls the completion callback to give us kind-of statistical
idea of how this callback is used. We can try:

  $ git grep base\.complete\( drivers/crypto/

Finally, by inspecting ahash_request_set_callback() implementation defined
in include/crypto/hash.h , we observe that the .data entry of 'struct
crypto_async_request' is intended for arbitrary data, not for completion

Signed-off-by: Marek Vasut <>
Cc: David S. Miller <>
Cc: Fabio Estevam <>
Cc: Herbert Xu <>
Cc: Shawn Guo <>
Cc: Tom Lendacky <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
5 years agocrypto: hash - Pull out the functions to save/restore request
Marek Vasut [Fri, 14 Mar 2014 01:37:05 +0000 (02:37 +0100)]
crypto: hash - Pull out the functions to save/restore request

commit 1ffc9fbd1e5071948b6d48f9a27d845738ee890f upstream.

The functions to save original request within a newly adjusted request
and it's counterpart to restore the original request can be re-used by
more code in the crypto/ahash.c file. Pull these functions out from the
code so they're available.

Signed-off-by: Marek Vasut <>
Cc: David S. Miller <>
Cc: Fabio Estevam <>
Cc: Herbert Xu <>
Cc: Shawn Guo <>
Cc: Tom Lendacky <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
5 years agocrypto: hash - Fix the pointer voodoo in unaligned ahash
Marek Vasut [Fri, 14 Mar 2014 01:37:04 +0000 (02:37 +0100)]
crypto: hash - Fix the pointer voodoo in unaligned ahash

commit ab6bf4e5e5e4298e8649e635bee25542cccbfd97 upstream.

Add documentation for the pointer voodoo that is happening in crypto/ahash.c
in ahash_op_unaligned(). This code is quite confusing, so add a beefy chunk
of documentation.

Moreover, make sure the mangled request is completely restored after finishing
this unaligned operation. This means restoring all of .result,
and .base.complete .

Also, remove the crypto_completion_t complete = ... line present in the
ahash_op_unaligned_done() function. This type actually declares a function
pointer, which is very confusing.

Finally, yet very important nonetheless, make sure the req->priv is free()'d
only after the original request is restored in ahash_op_unaligned_done().
The req->priv data must not be free()'d before that in ahash_op_unaligned_finish(),
since we would be accessing previously free()'d data in ahash_op_unaligned_done()
and cause corruption.

Signed-off-by: Marek Vasut <>
Cc: David S. Miller <>
Cc: Fabio Estevam <>
Cc: Herbert Xu <>
Cc: Shawn Guo <>
Cc: Tom Lendacky <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
5 years agocrypto: ahash - Fully restore ahash request before completing
Marek Vasut [Tue, 10 Dec 2013 19:26:19 +0000 (20:26 +0100)]
crypto: ahash - Fully restore ahash request before completing

commit 1d9a394b97b833d3ab37f49caf12d0be3c88050b upstream.

When finishing the ahash request, the ahash_op_unaligned_done() will
call complete() on the request. Yet, this will not call the correct
complete callback. The correct complete callback was previously stored
in the requests' private data, as seen in ahash_op_unaligned(). This
patch restores the correct complete callback and .data field of the
request before calling complete() on it.

Signed-off-by: Marek Vasut <>
Cc: David S. Miller <>
Cc: Fabio Estevam <>
Cc: Shawn Guo <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
5 years agomm/mempolicy.c: fix error handling in set_mempolicy and mbind.
Chris Salls [Sat, 8 Apr 2017 06:48:11 +0000 (23:48 -0700)]
mm/mempolicy.c: fix error handling in set_mempolicy and mbind.

commit cf01fb9985e8deb25ccf0ea54d916b8871ae0e62 upstream.

In the case that compat_get_bitmap fails we do not want to copy the
bitmap to the user as it will contain uninitialized stack data and leak
sensitive data.

Signed-off-by: Chris Salls <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agoKEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
Eric Biggers [Tue, 18 Apr 2017 14:31:09 +0000 (15:31 +0100)]
KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings

commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.

This fixes CVE-2017-7472.

Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:

#include <keyutils.h>

int main()
for (;;)

Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.

Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agonet/packet: fix overflow in check for tp_reserve
Andrey Konovalov [Wed, 29 Mar 2017 14:11:22 +0000 (16:11 +0200)]
net/packet: fix overflow in check for tp_reserve

commit bcc5364bdcfe131e6379363f089e7b4108d35b70 upstream.

When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.

Fix by checking that tp_reserve <= INT_MAX on assign.

Signed-off-by: Andrey Konovalov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agonet/packet: fix overflow in check for tp_frame_nr
Andrey Konovalov [Wed, 29 Mar 2017 14:11:21 +0000 (16:11 +0200)]
net/packet: fix overflow in check for tp_frame_nr

commit 8f8d28e4d6d815a391285e121c3a53a0b6cb9e7b upstream.

When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow.

Add a check that tp_block_size * tp_block_nr <= UINT_MAX.

Since frames_per_block <= tp_block_size, the expression would
never overflow.

Signed-off-by: Andrey Konovalov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agonet/packet: fix overflow in check for priv area size
Andrey Konovalov [Wed, 29 Mar 2017 14:11:20 +0000 (16:11 +0200)]
net/packet: fix overflow in check for priv area size

commit 2b6867c2ce76c596676bec7d2d525af525fdc6e2 upstream.

Subtracting tp_sizeof_priv from tp_block_size and casting to int
to check whether one is less then the other doesn't always work
(both of them are unsigned ints).

Compare them as is instead.

Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as
it can overflow inside BLK_PLUS_PRIV otherwise.

Signed-off-by: Andrey Konovalov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agopacket: handle too big packets for PACKET_V3
Eric Dumazet [Fri, 15 Aug 2014 16:16:04 +0000 (09:16 -0700)]
packet: handle too big packets for PACKET_V3

commit dc808110bb62b64a448696ecac3938902c92e1ab upstream.

af_packet can currently overwrite kernel memory by out of bound
accesses, because it assumed a [new] block can always hold one frame.

This is not generally the case, even if most existing tools do it right.

This patch clamps too long frames as API permits, and issue a one time
error on syslog.

[  394.357639] tpacket_rcv: packet too big, clamped from 5042 to 3966. macoff=82

In this example, packet header tp_snaplen was set to 3966,
and tp_len was set to 5042 (skb->len)

Signed-off-by: Eric Dumazet <>
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Acked-by: Daniel Borkmann <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agodrm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()
Li Qiang [Tue, 28 Mar 2017 03:10:53 +0000 (20:10 -0700)]
drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()

commit e7e11f99564222d82f0ce84bd521e57d78a6b678 upstream.

In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the
'req->mip_levels' array. This array can be assigned any value from
the user space. As both the 'num_sizes' and the array is uint32_t,
it is easy to make 'num_sizes' overflow. The later 'mip_levels' is
used as the loop count. This can lead an oob write. Add the check of
'req->mip_levels' to avoid this.

Signed-off-by: Li Qiang <>
Reviewed-by: Thomas Hellstrom <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agodrm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()
Murray McAllister [Mon, 27 Mar 2017 09:12:53 +0000 (11:12 +0200)]
drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()

commit 36274ab8c596f1240c606bb514da329add2a1bcd upstream.

Before memory allocations vmw_surface_define_ioctl() checks the
upper-bounds of a user-supplied size, but does not check if the
supplied size is 0.

Add check to avoid NULL pointer dereferences.

Signed-off-by: Murray McAllister <>
Reviewed-by: Sinclair Yeh <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agoxfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
Andy Whitcroft [Thu, 23 Mar 2017 07:45:44 +0000 (07:45 +0000)]
xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

commit f843ee6dd019bcece3e74e76ad9df0155655d0df upstream.

Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
wrapping issues.  To ensure we are correctly ensuring that the two ESN
structures are the same size compare both the overall size as reported
by xfrm_replay_state_esn_len() and the internal length are the same.

Signed-off-by: Andy Whitcroft <>
Acked-by: Steffen Klassert <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agoxfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
Andy Whitcroft [Wed, 22 Mar 2017 07:29:31 +0000 (07:29 +0000)]
xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window

commit 677e806da4d916052585301785d847c3b3e6186a upstream.

When a new xfrm state is created during an XFRM_MSG_NEWSA call we
validate the user supplied replay_esn to ensure that the size is valid
and to ensure that the replay_window size is within the allocated
buffer.  However later it is possible to update this replay_esn via a
XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
buffer matches the existing state and if so inject the contents.  We do
not at this point check that the replay_window is within the allocated
memory.  This leads to out-of-bounds reads and writes triggered by
netlink packets.  This leads to memory corruption and the potential for
priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained

Signed-off-by: Andy Whitcroft <>
Acked-by: Steffen Klassert <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agoping: implement proper locking
Eric Dumazet [Sat, 25 Mar 2017 02:36:13 +0000 (19:36 -0700)]
ping: implement proper locking

commit 43a6684519ab0a6c52024b5e25322476cabad893 upstream.

We got a report of yet another bug in ping

->disconnect() is not called with socket lock held.

Fix this by acquiring ping rwlock earlier.

Thanks to Daniel, Alexander and Andrey for letting us know this problem.

Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Eric Dumazet <>
Reported-by: Daniel Jiang <>
Reported-by: Solar Designer <>
Reported-by: Andrey Konovalov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoKEYS: Disallow keyrings beginning with '.' to be joined as session keyrings
David Howells [Tue, 18 Apr 2017 14:31:07 +0000 (15:31 +0100)]
KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings

commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream.

This fixes CVE-2016-9604.

Keyrings whose name begin with a '.' are special internal keyrings and so
userspace isn't allowed to create keyrings by this name to prevent
shadowing.  However, the patch that added the guard didn't fix
KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
it can also subscribe to them as a session keyring if they grant SEARCH
permission to the user.

This, for example, allows a root process to set .builtin_trusted_keys as
its session keyring, at which point it has full access because now the
possessor permissions are added.  This permits root to add extra public
keys, thereby bypassing module verification.

This also affects kexec and IMA.

This can be tested by (as root):

keyctl session .builtin_trusted_keys
keyctl add user a a @s
keyctl list @s

which on my test box gives me:

2 keys in keyring:
180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
801382539: --alswrv     0     0 user: a

Fix this by rejecting names beginning with a '.' in the keyctl.

Signed-off-by: David Howells <>
Acked-by: Mimi Zohar <>
Signed-off-by: Ben Hutchings <>
5 years agoKEYS: Reinstate EPERM for a key type name beginning with a '.'
David Howells [Tue, 16 Sep 2014 16:29:03 +0000 (17:29 +0100)]
KEYS: Reinstate EPERM for a key type name beginning with a '.'

commit 54e2c2c1a9d6cbb270b0999a38545fa9a69bee43 upstream.

Reinstate the generation of EPERM for a key type name beginning with a '.' in
a userspace call.  Types whose name begins with a '.' are internal only.

The test was removed by:

commit a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d
Author: Mimi Zohar <>
Date:   Thu May 22 14:02:23 2014 -0400
Subject: KEYS: special dot prefixed keyring name bug fix

I think we want to keep the restriction on type name so that userspace can't
add keys of a special internal type.

Note that removal of the test causes several of the tests in the keyutils
testsuite to fail.

Signed-off-by: David Howells <>
Acked-by: Vivek Goyal <>
cc: Mimi Zohar <>
Signed-off-by: Ben Hutchings <>
5 years agoKEYS: special dot prefixed keyring name bug fix
Mimi Zohar [Thu, 22 May 2014 18:02:23 +0000 (14:02 -0400)]
KEYS: special dot prefixed keyring name bug fix

commit a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d upstream.

Dot prefixed keyring names are supposed to be reserved for the
kernel, but add_key() calls key_get_type_from_user(), which
incorrectly verifies the 'type' field, not the 'description' field.
This patch verifies the 'description' field isn't dot prefixed,
when creating a new keyring, and removes the dot prefix test in

Changelog v6:
- whitespace and other cleanup

Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not
  regular keys  - Dmitry

Reported-by: Dmitry Kasatkin <>
Signed-off-by: Mimi Zohar <>
Acked-by: David Howells <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
5 years agoUSB: iowarrior: fix NULL-deref at probe
Johan Hovold [Tue, 7 Mar 2017 15:11:03 +0000 (16:11 +0100)]
USB: iowarrior: fix NULL-deref at probe

commit b7321e81fc369abe353cf094d4f0dc2fe11ab95f upstream.

Make sure to check for the required interrupt-in endpoint to avoid
dereferencing a NULL-pointer should a malicious device lack such an

Note that a fairly recent change purported to fix this issue, but added
an insufficient test on the number of endpoints only, a test which can
now be removed.

Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB descriptors")
Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoALSA: seq: Fix link corruption by event error handling
Takashi Iwai [Tue, 28 Feb 2017 21:15:51 +0000 (22:15 +0100)]
ALSA: seq: Fix link corruption by event error handling

commit f3ac9f737603da80c2da3e84b89e74429836bb6d upstream.

The sequencer FIFO management has a bug that may lead to a corruption
(shortage) of the cell linked list.  When a sequencer client faces an
error at the event delivery, it tries to put back the dequeued cell.
When the first queue was put back, this forgot the tail pointer
tracking, and the link will be screwed up.

Although there is no memory corruption, the sequencer client may stall
forever at exit while flushing the pending FIFO cells in
snd_seq_pool_done(), as spotted by syzkaller.

This patch addresses the missing tail pointer tracking at
snd_seq_fifo_cell_putback().  Also the patch makes sure to clear the
cell->enxt pointer at snd_seq_fifo_event_in() for avoiding a similar
mess-up of the FIFO linked list.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
5 years agoALSA: ctxfi: Fallback DMA mask to 32bit
Takashi Iwai [Tue, 28 Feb 2017 16:16:48 +0000 (17:16 +0100)]
ALSA: ctxfi: Fallback DMA mask to 32bit

commit 15c75b09f8d190f89ab4db463b87d411ca349dfe upstream.

Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit
architectures, and bails out if it fails.  This causes a problem on
some platforms since the 64bit DMA isn't always guaranteed.  We should
fall back to the default 32bit DMA when 64bit DMA fails.

Fixes: 6d74b86d3c0f ("ALSA: ctxfi - Allow 64bit DMA")
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2:
 - Old code was using PCI DMA mask functions
 - Deleted error message was different]
Signed-off-by: Ben Hutchings <>
5 years agoALSA: timer: Reject user params with too small ticks
Takashi Iwai [Tue, 28 Feb 2017 13:49:07 +0000 (14:49 +0100)]
ALSA: timer: Reject user params with too small ticks

commit 71321eb3f2d0df4e6c327e0b936eec4458a12054 upstream.

When a user sets a too small ticks with a fine-grained timer like
hrtimer, the kernel tries to fire up the timer irq too frequently.
This may lead to the condensed locks, eventually the kernel spinlock
lockup with warnings.

For avoiding such a situation, we define a lower limit of the
resolution, namely 1ms.  When the user passes a too small tick value
that results in less than that, the kernel returns -EINVAL now.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
5 years agonet sched actions: decrement module reference count after table flush.
Roman Mashak [Fri, 24 Feb 2017 16:00:32 +0000 (11:00 -0500)]
net sched actions: decrement module reference count after table flush.

commit edb9d1bff4bbe19b8ae0e71b1f38732591a9eeb2 upstream.

When tc actions are loaded as a module and no actions have been installed,
flushing them would result in actions removed from the memory, but modules
reference count not being decremented, so that the modules would not be

Following is example with GACT action:

% sudo modprobe act_gact
% lsmod
Module                  Size  Used by
act_gact               16384  0
% sudo tc actions ls action gact
% sudo tc actions flush action gact
% lsmod
Module                  Size  Used by
act_gact               16384  1
% sudo tc actions flush action gact
% lsmod
Module                  Size  Used by
act_gact               16384  2
% sudo rmmod act_gact
rmmod: ERROR: Module act_gact is in use

After the fix:
% lsmod
Module                  Size  Used by
act_gact               16384  0
% sudo tc actions add action pass index 1
% sudo tc actions add action pass index 2
% sudo tc actions add action pass index 3
% lsmod
Module                  Size  Used by
act_gact               16384  3
% sudo tc actions flush action gact
% lsmod
Module                  Size  Used by
act_gact               16384  0
% sudo tc actions flush action gact
% lsmod
Module                  Size  Used by
act_gact               16384  0
% sudo rmmod act_gact
% lsmod
Module                  Size  Used by

Fixes: f97017cdefef ("net-sched: Fix actions flushing")
Signed-off-by: Roman Mashak <>
Signed-off-by: Jamal Hadi Salim <>
Acked-by: Cong Wang <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoNFSv4: fix getacl ERANGE for some ACL buffer sizes
Weston Andros Adamson [Thu, 23 Feb 2017 19:54:21 +0000 (14:54 -0500)]
NFSv4: fix getacl ERANGE for some ACL buffer sizes

commit ed92d8c137b7794c2c2aa14479298b9885967607 upstream.

We're not taking into account that the space needed for the (variable
length) attr bitmap, with the result that we'd sometimes get a spurious
ERANGE when the ACL data got close to the end of a page.

Just add in an extra page to make sure.

Signed-off-by: Weston Andros Adamson <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Anna Schumaker <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoNFSv4: Fix range checking in __nfs4_get_acl_uncached and __nfs4_proc_set_acl
Trond Myklebust [Fri, 24 Aug 2012 14:59:25 +0000 (10:59 -0400)]
NFSv4: Fix range checking in __nfs4_get_acl_uncached and __nfs4_proc_set_acl

commit 21f498c2f73bd6150d82931f09965826dca0b5f2 upstream.

Ensure that the user supplied buffer size doesn't cause us to overflow
the 'pages' array.

Also fix up some confusion between the use of PAGE_SIZE and
PAGE_CACHE_SIZE when calculating buffer sizes. We're not using
the page cache for anything here.

Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>