5 years agoxen-blkback: don't leak stack data via response ring
Jan Beulich [Tue, 13 Jun 2017 20:28:27 +0000 (16:28 -0400)]
xen-blkback: don't leak stack data via response ring

commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 upstream.

Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).

This is XSA-216.

Signed-off-by: Jan Beulich <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Konrad Rzeszutek Wilk <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agomm: Tighten x86 /dev/mem with zeroing reads
Kees Cook [Wed, 5 Apr 2017 16:39:08 +0000 (09:39 -0700)]
mm: Tighten x86 /dev/mem with zeroing reads

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala <>
Tested-by: Tommi Rantala <>
Signed-off-by: Kees Cook <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agox86/mm/init.c: Fix devmem_is_allowed() off by one
T Makphaibulchoke [Wed, 29 Aug 2012 03:21:43 +0000 (21:21 -0600)]
x86/mm/init.c: Fix devmem_is_allowed() off by one

commit 73e8f3d7e2cb23614d5115703d76d8e54764b641 upstream.

Fixing an off-by-one error in devmem_is_allowed(), which allows
accesses to physical addresses 0x100000-0x100fff, an extra page
past 1MB.

Signed-off-by: T Makphaibulchoke <>
Acked-by: H. Peter Anvin <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
5 years agoInput: i8042 - add Clevo P650RS to the i8042 reset list
Dmitry Torokhov [Thu, 13 Apr 2017 22:36:31 +0000 (15:36 -0700)]
Input: i8042 - add Clevo P650RS to the i8042 reset list

commit 7c5bb4ac2b76d2a09256aec8a7d584bf3e2b0466 upstream.

Clevo P650RS and other similar devices require i8042 to be reset in order
to detect Synaptics touchpad.

Reported-by: Paweł Bylica <>
Tested-by: Ed Bordin <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
5 years agonet: tc35815: move free after the dereference
Dan Carpenter [Fri, 21 Apr 2017 10:49:37 +0000 (13:49 +0300)]
net: tc35815: move free after the dereference

commit 11faa7b0359aaf7efd406b7a6a077fda2b037d8e upstream.

We dereference "skb" to get "skb->len" so we should probably do that
step before freeing the skb.

Fixes: eea221ce4880 ("tc35815 driver update (take 2)")
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agocx82310_eth: use skb_cow_head() to deal with cloned skbs
Eric Dumazet [Wed, 19 Apr 2017 16:59:22 +0000 (09:59 -0700)]
cx82310_eth: use skb_cow_head() to deal with cloned skbs

commit a9e840a2081ed28c2b7caa6a9a0041c950b3c37d upstream.

We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.

skb_cow_head() is the proper helper to deal with this.

Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver")
Signed-off-by: Eric Dumazet <>
Cc: James Hughes <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agosmsc75xx: use skb_cow_head() to deal with cloned skbs
Eric Dumazet [Wed, 19 Apr 2017 16:59:21 +0000 (09:59 -0700)]
smsc75xx: use skb_cow_head() to deal with cloned skbs

commit b7c6d2675899cfff0180412c63fc9cbd5bacdb4d upstream.

We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.

skb_cow_head() is the proper helper to deal with this.

Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
Signed-off-by: Eric Dumazet <>
Cc: James Hughes <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agomac80211: reject ToDS broadcast data frames
Johannes Berg [Thu, 20 Apr 2017 19:32:16 +0000 (21:32 +0200)]
mac80211: reject ToDS broadcast data frames

commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream.

AP/AP_VLAN modes don't accept any real 802.11 multicast data
frames, but since they do need to accept broadcast management
frames the same is currently permitted for data frames. This
opens a security problem because such frames would be decrypted
with the GTK, and could even contain unicast L3 frames.

Since the spec says that ToDS frames must always have the BSSID
as the RA (addr1), reject any other data frames.

The problem was originally reported in "Predicting, Decrypting,
and Abusing WPA2/802.11 Group Keys" at usenix
and brought to my attention by Jouni.

Reported-by: Jouni Malinen <>
Signed-off-by: Johannes Berg <>
Dave, I didn't want to send you a new pull request for a single
commit yet again - can you apply this one patch as is?
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: Put the new code in an else-block since the
 previous if-blocks may or may not return]
Signed-off-by: Ben Hutchings <>
5 years agoring-buffer: Have ring_buffer_iter_empty() return true when empty
Steven Rostedt (VMware) [Wed, 19 Apr 2017 18:29:46 +0000 (14:29 -0400)]
ring-buffer: Have ring_buffer_iter_empty() return true when empty

commit 78f7a45dac2a2d2002f98a3a95f7979867868d73 upstream.

I noticed that reading the snapshot file when it is empty no longer gives a
status. It suppose to show the status of the snapshot buffer as well as how
to allocate and use it. For example:

 ># cat snapshot
 # tracer: nop
 # * Snapshot is allocated *
 # Snapshot commands:
 # echo 0 > snapshot : Clears and frees snapshot buffer
 # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
 #                      Takes a snapshot of the main buffer.
 # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
 #                      (Doesn't have to be '2' works with any number that
 #                       is not a '0' or '1')

But instead it just showed an empty buffer:

 ># cat snapshot
 # tracer: nop
 # entries-in-buffer/entries-written: 0/0   #P:4
 #                              _-----=> irqs-off
 #                             / _----=> need-resched
 #                            | / _---=> hardirq/softirq
 #                            || / _--=> preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |

What happened was that it was using the ring_buffer_iter_empty() function to
see if it was empty, and if it was, it showed the status. But that function
was returning false when it was empty. The reason was that the iter header
page was on the reader page, and the reader page was empty, but so was the
buffer itself. The check only tested to see if the iter was on the commit
page, but the commit page was no longer pointing to the reader page, but as
all pages were empty, the buffer is also.

Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page")
Signed-off-by: Steven Rostedt (VMware) <>
Signed-off-by: Ben Hutchings <>
5 years agoACPI / power: Avoid maybe-uninitialized warning
Arnd Bergmann [Wed, 19 Apr 2017 17:47:04 +0000 (19:47 +0200)]
ACPI / power: Avoid maybe-uninitialized warning

commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream.

gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
is enterered at least once, so it assumes that cur_state might not get

drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This sets the variable to zero at the start of the loop, to ensure that
there is well-defined behavior even for an empty list. This gets rid of
the warning.

The warning first showed up when the -Os flag got removed in a bug fix
patch in linux-4.11-rc5.

I would suggest merging this addon patch on top of that bug fix to avoid
introducing a new warning in the stable kernels.

Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing)
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoKEYS: Change the name of the dead type to ".dead" to prevent user access
David Howells [Tue, 18 Apr 2017 14:31:08 +0000 (15:31 +0100)]
KEYS: Change the name of the dead type to ".dead" to prevent user access

commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.

This fixes CVE-2017-6951.

Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs.  Attempting to use it may cause the kernel to crash.

Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().

Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:

commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
Author: David Howells <>
Date:   Tue Sep 16 17:36:06 2014 +0100
KEYS: Remove key_type::match in favour of overriding default by match_preparse

which went in before 3.18-rc1.

Signed-off-by: David Howells <>
Signed-off-by: Ben Hutchings <>
5 years agop9_client_readdir() fix
Al Viro [Fri, 14 Apr 2017 21:22:18 +0000 (17:22 -0400)]
p9_client_readdir() fix

commit 71d6ad08379304128e4bdfaf0b4185d54375423e upstream.

Don't assume that server is sane and won't return more data than
asked for.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
5 years agoftrace/x86: Fix triple fault with graph tracing and suspend-to-ram
Josh Poimboeuf [Thu, 13 Apr 2017 22:53:55 +0000 (17:53 -0500)]
ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram

commit 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 upstream.

On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
graph tracing and then suspend to RAM, it will triple fault and reboot when
it resumes.

The first fault happens when booting a secondary CPU:

        (accesses 'kill_ftrace_graph')

The early head_32.S code calls into load_ucode_ap(), which has an an
ftrace hook, so it calls prepare_ftrace_return(), which calls
ftrace_graph_is_dead(), which tries to access the global
'kill_ftrace_graph' variable with a virtual address, causing a fault
because the CPU is still in real mode.

The fix is to add a check in prepare_ftrace_return() to make sure it's
running in protected mode before continuing.  The check makes sure the
stack pointer is a virtual kernel address.  It's a bit of a hack, but
it's not very intrusive and it works well enough.

For reference, here are a few other (more difficult) ways this could
have potentially been fixed:

- Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
  is enabled.  (No idea what that would break.)

- Track down load_ucode_ap()'s entire callee tree and mark all the
  functions 'notrace'.  (Probably not realistic.)

- Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
  or __cpu_up(), and ensure that the pause facility can be queried from
  real mode.

Reported-by: Paul Menzel <>
Signed-off-by: Josh Poimboeuf <>
Tested-by: Paul Menzel <>
Reviewed-by: Steven Rostedt (VMware) <>
Cc: "Rafael J . Wysocki" <>
Cc: Borislav Petkov <>
Cc: Len Brown <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agocpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores
Ben Hutchings [Mon, 10 Apr 2017 23:29:44 +0000 (00:29 +0100)]
cpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores

commit 4cca0457686e4ee1677d69469e4ddfd94d389a80 upstream.

The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and
CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both
flags set and an assumed base clock of 100 MHz for turbo values.

Reported-by: GSR <>
Tested-by: GSR <>
Fixes: 8fb2e440b223 (cpupower: Show Intel turbo ratio support via ...)
Signed-off-by: Ben Hutchings <>
Signed-off-by: Rafael J. Wysocki <>
5 years agoALSA: seq: Don't break snd_use_lock_sync() loop by timeout
Takashi Iwai [Sun, 9 Apr 2017 08:41:27 +0000 (10:41 +0200)]
ALSA: seq: Don't break snd_use_lock_sync() loop by timeout

commit 4e7655fd4f47c23e5249ea260dc802f909a64611 upstream.

The snd_use_lock_sync() (thus its implementation
snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of
the sync loop.  It was introduced from the beginning, just to be
"safer", in terms of avoiding the stupid bugs.

However, as Ben Hutchings suggested, this timeout rather introduces a
potential leak or use-after-free that was apparently fixed by the
commit 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize"):
for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() ->
copy_from_user() could block for a long time, and snd_use_lock_sync()
goes timeout and still leaves the cell at releasing the pool.

For fixing such a problem, we remove the break by the timeout while
still keeping the warning.

Suggested-by: Ben Hutchings <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoMIPS: KGDB: Use kernel context for sleeping threads
James Hogan [Thu, 30 Mar 2017 15:06:02 +0000 (16:06 +0100)]
MIPS: KGDB: Use kernel context for sleeping threads

commit 162b270c664dca2e0944308e92f9fcc887151a72 upstream.

KGDB is a kernel debug stub and it can't be used to debug userland as it
can only safely access kernel memory.

On MIPS however KGDB has always got the register state of sleeping
processes from the userland register context at the beginning of the
kernel stack. This is meaningless for kernel threads (which never enter
userland), and for user threads it prevents the user seeing what it is
doing while in the kernel:

(gdb) info threads
  Id   Target Id         Frame
  3    Thread 2 (kthreadd) 0x0000000000000000 in ?? ()
  2    Thread 1 (init)   0x000000007705c4b4 in ?? ()
  1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201

Get the register state instead from the (partial) kernel register
context stored in the task's thread_struct for resume() to restore. All
threads now correctly appear to be in context_switch():

(gdb) info threads
  Id   Target Id         Frame
  3    Thread 2 (kthreadd) context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
  2    Thread 1 (init)   context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
  1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201

Call clobbered registers which aren't saved and exception registers
(BadVAddr & Cause) which can't be easily determined without stack
unwinding are reported as 0. The PC is taken from the return address,
such that the state presented matches that found immediately after
returning from resume().

Fixes: 8854700115ec ("[MIPS] kgdb: add arch support for the kernel's kgdb core")
Signed-off-by: James Hogan <>
Cc: Jason Wessel <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
5 years agox86/vdso: Plug race between mapping and ELF header setup
Thomas Gleixner [Mon, 10 Apr 2017 15:14:28 +0000 (17:14 +0200)]
x86/vdso: Plug race between mapping and ELF header setup

commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 upstream.

The vsyscall32 sysctl can racy against a concurrent fork when it switches
from disabled to enabled:

if (vdso32_enabled)
           --> No mapping
                                          --> vdso32_enabled = true
        if (vdso32_enabled) {
           --> Add VDSO entry with NULL pointer

Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
the newly forked process or not.

Signed-off-by: Thomas Gleixner <>
Acked-by: Andy Lutomirski <>
Cc: Peter Zijlstra <>
Cc: Mathias Krause <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: change the flag passed to ARCH_DLINFO_IA32()]
Signed-off-by: Ben Hutchings <>
5 years agol2tp: don't mask errors in pppol2tp_getsockopt()
Guillaume Nault [Thu, 6 Apr 2017 16:31:21 +0000 (18:31 +0200)]
l2tp: don't mask errors in pppol2tp_getsockopt()

commit 321a52a39189d5e4af542f7dcdc07bba4545cf5d upstream.

pppol2tp_getsockopt() doesn't take into account the error code returned
by pppol2tp_tunnel_getsockopt() or pppol2tp_session_getsockopt(). If
error occurs there, pppol2tp_getsockopt() continues unconditionally and
reports erroneous values.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agol2tp: don't mask errors in pppol2tp_setsockopt()
Guillaume Nault [Thu, 6 Apr 2017 16:31:20 +0000 (18:31 +0200)]
l2tp: don't mask errors in pppol2tp_setsockopt()

commit 364700cf8fd54f54ad08313464105a414e3bccb7 upstream.

pppol2tp_setsockopt() unconditionally overwrites the error value
returned by pppol2tp_tunnel_setsockopt() or
pppol2tp_session_setsockopt(), thus hiding errors from userspace.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agoptrace: fix PTRACE_LISTEN race corrupting task->state [Fri, 7 Apr 2017 23:04:51 +0000 (16:04 -0700)]
ptrace: fix PTRACE_LISTEN race corrupting task->state

commit 5402e97af667e35e54177af8f6575518bf251d51 upstream.

In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
__TASK_TRACED.  If this races with the ptrace_unfreeze_traced at the end
of a PTRACE_LISTEN, this can wake the task /after/ the check against
__TASK_TRACED, but before the reset of state to TASK_TRACED.  This
causes it to instead clobber TASK_WAKING, allowing a subsequent wakeup
against TRACED while the task is still on the rq wake_list, corrupting

Oleg said:
 "The kernel can crash or this can lead to other hard-to-debug problems.
  In short, "task->state = TASK_TRACED" in ptrace_unfreeze_traced()
  assumes that nobody else can wake it up, but PTRACE_LISTEN breaks the
  contract. Obviusly it is very wrong to manipulate task->state if this
  task is already running, or WAKING, or it sleeps again"

[ coding-style fixes]
Fixes: 9899d11f ("ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL")
Signed-off-by: Ben Segall <>
Acked-by: Oleg Nesterov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
5 years agoscsi: sd: Fix capacity calculation with 32-bit sector_t
Martin K. Petersen [Tue, 4 Apr 2017 14:42:30 +0000 (10:42 -0400)]
scsi: sd: Fix capacity calculation with 32-bit sector_t

commit 7c856152cb92f8eee2df29ef325a1b1f43161aff upstream.

We previously made sure that the reported disk capacity was less than
0xffffffff blocks when the kernel was not compiled with large sector_t
support (CONFIG_LBDAF). However, this check assumed that the capacity
was reported in units of 512 bytes.

Add a sanity check function to ensure that we only enable disks if the
entire reported capacity can be expressed in terms of sector_t.

Reported-by: Steve Magnani <>
Cc: Bart Van Assche <>
Reviewed-by: Bart Van Assche <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: use integer literal instead of U32_MAX]
Signed-off-by: Ben Hutchings <>
5 years agoscsi: sr: Sanity check returned mode data
Martin K. Petersen [Fri, 17 Mar 2017 12:47:14 +0000 (08:47 -0400)]
scsi: sr: Sanity check returned mode data

commit a00a7862513089f17209b732f230922f1942e0b9 upstream.

Kefeng Wang discovered that old versions of the QEMU CD driver would
return mangled mode data causing us to walk off the end of the buffer in
an attempt to parse it. Sanity check the returned mode sense data.

Reported-by: Kefeng Wang <>
Tested-by: Kefeng Wang <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
5 years agoxen, fbfront: fix connecting to backend
Juergen Gross [Fri, 7 Apr 2017 15:28:23 +0000 (17:28 +0200)]
xen, fbfront: fix connecting to backend

commit 9121b15b5628b38b4695282dc18c553440e0f79b upstream.

Connecting to the backend isn't working reliably in xen-fbfront: in
case XenbusStateInitWait of the backend has been missed the backend
transition to XenbusStateConnected will trigger the connected state
only without doing the actions required when the backend has

Signed-off-by: Juergen Gross <>
Reviewed-by: Boris Ostrovsky <>
Signed-off-by: Bartlomiej Zolnierkiewicz <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
5 years agol2tp: take reference on sessions being dumped
Guillaume Nault [Mon, 3 Apr 2017 10:03:13 +0000 (12:03 +0200)]
l2tp: take reference on sessions being dumped

commit e08293a4ccbcc993ded0fdc46f1e57926b833d63 upstream.

Take a reference on the sessions returned by l2tp_session_find_nth()
(and rename it l2tp_session_get_nth() to reflect this change), so that
caller is assured that the session isn't going to disappear while
processing it.

For procfs and debugfs handlers, the session is held in the .start()
callback and dropped in .show(). Given that pppol2tp_seq_session_show()
dereferences the associated PPPoL2TP socket and that
l2tp_dfs_seq_session_show() might call pppol2tp_show(), we also need to
call the session's .ref() callback to prevent the socket from going
away from under us.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Fixes: 0ad6614048cf ("l2tp: Add debugfs files for dumping l2tp debug info")
Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agopowerpc: Don't try to fix up misaligned load-with-reservation instructions
Paul Mackerras [Tue, 4 Apr 2017 04:56:05 +0000 (14:56 +1000)]
powerpc: Don't try to fix up misaligned load-with-reservation instructions

commit 48fe9e9488743eec9b7c1addd3c93f12f2123d54 upstream.

In the past, there was only one load-with-reservation instruction,
lwarx, and if a program attempted a lwarx on a misaligned address, it
would take an alignment interrupt and the kernel handler would emulate
it as though it was lwzx, which was not really correct, but benign since
it is loading the right amount of data, and the lwarx should be paired
with a stwcx. to the same address, which would also cause an alignment
interrupt which would result in a SIGBUS being delivered to the process.

We now have 5 different sizes of load-with-reservation instruction. Of
those, lharx and ldarx cause an immediate SIGBUS by luck since their
entries in aligninfo[] overlap instructions which were not fixed up, but
lqarx overlaps with lhz and will be emulated as such. lbarx can never
generate an alignment interrupt since it only operates on 1 byte.

To straighten this out and fix the lqarx case, this adds code to detect
the l[hwdq]arx instructions and return without fixing them up, resulting
in a SIGBUS being delivered to the process.

Signed-off-by: Paul Mackerras <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2: open-code get_xop()]
Signed-off-by: Ben Hutchings <>
5 years agoaf_key: Add lock to key dump
Yuejie Shi [Fri, 31 Mar 2017 07:10:20 +0000 (15:10 +0800)]
af_key: Add lock to key dump

commit 89e357d83c06b6fac581c3ca7f0ee3ae7e67109e upstream.

A dump may come in the middle of another dump, modifying its dump
structure members. This race condition will result in NULL pointer
dereference in kernel. So add a lock to prevent that race.

Fixes: 83321d6b9872 ("[AF_KEY]: Dump SA/SP entries non-atomically")
Signed-off-by: Yuejie Shi <>
Signed-off-by: Steffen Klassert <>
[bwh: Backported to 3.2:
 - pfkey_dump() doesn't support filters
 - Adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoiscsi-target: Drop work-around for legacy GlobalSAN initiator
Nicholas Bellinger [Sun, 2 Apr 2017 20:36:44 +0000 (13:36 -0700)]
iscsi-target: Drop work-around for legacy GlobalSAN initiator

commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 upstream.

Once upon a time back in 2009, a work-around was added to support
the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
did not propose nor respond to MaxBurstLength, FirstBurstLength,
DefaultTime2Wait and DefaultTime2Retain keys.

The work-around in iscsi_check_proposer_for_optional_reply()
allowed the missing keys to be proposed, but did not require
waiting for a response before moving to full feature phase
operation.  This allowed GlobalSAN v3.3 to work out-of-the
box, and for many years we didn't run into login interopt
issues with any other initiators..

Until recently, when Martin tried a QLogic 57840S iSCSI Offload
HBA on Windows 2016 which completed login, but subsequently
failed with:

    Got unknown iSCSI OpCode: 0x43

The issue was QLogic MSFT side did not propose DefaultTime2Wait +
DefaultTime2Retain, so LIO proposes them itself, and immediately
transitions to full feature phase because of the GlobalSAN hack.
However, the QLogic MSFT side still attempts to respond to
DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
in last login response.

So while the QLogic MSFT side should have been proposing these
two keys to start, it was doing the correct thing per RFC-3720
attempting to respond to proposed keys before transitioning to
full feature phase.

All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
does correctly propose the four keys during login, making the
original work-around moot.

So in order to allow QLogic MSFT to run unmodified as-is, go
ahead and drop this long standing work-around.

Reported-by: Martin Svec <>
Cc: Martin Svec <>
Cc: Himanshu Madhani <>
Cc: Arun Easi <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
5 years agol2tp: take a reference on sessions used in genetlink handlers
Guillaume Nault [Fri, 31 Mar 2017 11:02:30 +0000 (13:02 +0200)]
l2tp: take a reference on sessions used in genetlink handlers

commit 2777e2ab5a9cf2b4524486c6db1517a6ded25261 upstream.

Callers of l2tp_nl_session_find() need to hold a reference on the
returned session since there's no guarantee that it isn't going to
disappear from under them.

Relying on the fact that no l2tp netlink message may be processed
concurrently isn't enough: sessions can be deleted by other means
(e.g. by closing the PPPOL2TP socket of a ppp pseudowire).

l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
function that may require a previous call to session->ref(). In
particular, for ppp pseudowires, the callback is l2tp_session_delete(),
which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
socket. The socket might already be gone at the moment
l2tp_session_delete() calls session->ref(), so we need to take a
reference during the session lookup. So we need to pass the do_ref
variable down to l2tp_session_get() and l2tp_session_get_by_ifname().

Since all callers have to be updated, l2tp_session_find_by_ifname() and
l2tp_nl_session_find() are renamed to reflect their new behaviour.

Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agol2tp: fix duplicate session creation
Guillaume Nault [Fri, 31 Mar 2017 11:02:27 +0000 (13:02 +0200)]
l2tp: fix duplicate session creation

commit dbdbc73b44782e22b3b4b6e8b51e7a3d245f3086 upstream.

l2tp_session_create() relies on its caller for checking for duplicate
sessions. This is racy since a session can be concurrently inserted
after the caller's verification.

Fix this by letting l2tp_session_create() verify sessions uniqueness
upon insertion. Callers need to be adapted to check for
l2tp_session_create()'s return code instead of calling

pppol2tp_connect() is a bit special because it has to work on existing
sessions (if they're not connected) or to create a new session if none
is found. When acting on a preexisting session, a reference must be
held or it could go away on us. So we have to use l2tp_session_get()
instead of l2tp_session_find() and drop the reference before exiting.

Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: add 'pos' parameter to
 hlist_for_each_entry{,_rcu}() calls]
Signed-off-by: Ben Hutchings <>
5 years agol2tp: ensure session can't get removed during pppol2tp_session_ioctl()
Guillaume Nault [Fri, 31 Mar 2017 11:02:26 +0000 (13:02 +0200)]
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()

commit 57377d63547861919ee634b845c7caa38de4a452 upstream.

Holding a reference on session is required before calling
pppol2tp_session_ioctl(). The session could get freed while processing the
ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
we also need to take a reference on it in l2tp_session_get().

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
5 years agol2tp: fix race in l2tp_recv_common()
Guillaume Nault [Fri, 31 Mar 2017 11:02:25 +0000 (13:02 +0200)]
l2tp: fix race in l2tp_recv_common()

commit 61b9a047729bb230978178bca6729689d0c50ca2 upstream.

Taking a reference on sessions in l2tp_recv_common() is racy; this
has to be done by the callers.

To this end, a new function is required (l2tp_session_get()) to
atomically lookup a session and take a reference on it. Callers then
have to manually drop this reference.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop changes to l2tp_ip6.c
 - Add 'pos' parameter to hlist_for_each_entry{,_rcu}() calls
 - Adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoserial: mxs-auart: Fix baudrate calculation
Uwe Kleine-König [Mon, 20 Mar 2017 09:05:38 +0000 (10:05 +0100)]
serial: mxs-auart: Fix baudrate calculation

commit a6040bc610554c66088fda3608ae5d6307c548e4 upstream.

The reference manual for the i.MX28 recommends to calculate the divisor

divisor = (UARTCLK * 32) / baud rate, rounded to the nearest integer

, so let's do this. For a typical setup of UARTCLK = 24 MHz and baud
rate = 115200 this changes the divisor from 6666 to 6667 and so the
actual baud rate improves from 115211.521 Bd (error ≅ 0.01 %) to
115194.240 Bd (error ≅ 0.005 %).

Signed-off-by: Uwe Kleine-König <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
5 years agoserial: mxs-auart: fix baud rate range
Stefan Wahren [Tue, 11 Aug 2015 11:46:01 +0000 (11:46 +0000)]
serial: mxs-auart: fix baud rate range

commit df57cf6a879502cd6e5559c1f2d6db12128e074f upstream.

Currently mxs-auart doesn't care correctly about the baud rate divisor.
According to reference manual the baud rate divisor must be between
0x000000EC and 0x003FFFC0. So calculate the possible baud rate range
and use it for uart_get_baud_rate().

Signed-off-by: Stefan Wahren <>
Reviewed-by: Fabio Estevam <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
5 years agommc: sdhci: Disable runtime pm when the sdio_irq is enabled
Hans de Goede [Sun, 26 Mar 2017 11:14:45 +0000 (13:14 +0200)]
mmc: sdhci: Disable runtime pm when the sdio_irq is enabled

commit 923713b357455cfb9aca2cd3429cb0806a724ed2 upstream.

SDIO cards may need clock to send the card interrupt to the host.

On a cherrytrail tablet with a RTL8723BS wifi chip, without this patch
pinging the tablet results in:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=78.6 ms
64 bytes from icmp_seq=2 ttl=64 time=1760 ms
64 bytes from icmp_seq=3 ttl=64 time=753 ms
64 bytes from icmp_seq=4 ttl=64 time=3.88 ms
64 bytes from icmp_seq=5 ttl=64 time=795 ms
64 bytes from icmp_seq=6 ttl=64 time=1841 ms
64 bytes from icmp_seq=7 ttl=64 time=810 ms
64 bytes from icmp_seq=8 ttl=64 time=1860 ms
64 bytes from icmp_seq=9 ttl=64 time=812 ms
64 bytes from icmp_seq=10 ttl=64 time=48.6 ms

Where as with this patch I get:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=3.96 ms
64 bytes from icmp_seq=2 ttl=64 time=1.97 ms
64 bytes from icmp_seq=3 ttl=64 time=17.2 ms
64 bytes from icmp_seq=4 ttl=64 time=2.46 ms
64 bytes from icmp_seq=5 ttl=64 time=2.83 ms
64 bytes from icmp_seq=6 ttl=64 time=1.40 ms
64 bytes from icmp_seq=7 ttl=64 time=2.10 ms
64 bytes from icmp_seq=8 ttl=64 time=1.40 ms
64 bytes from icmp_seq=9 ttl=64 time=2.04 ms
64 bytes from icmp_seq=10 ttl=64 time=1.40 ms

Cc: Dong Aisheng <>
Signed-off-by: Hans de Goede <>
Acked-by: Adrian Hunter <>
Acked-by: Dong Aisheng <>
Signed-off-by: Ulf Hansson <>
Signed-off-by: Ben Hutchings <>
5 years agodrm/vmwgfx: Remove getparam error message
Thomas Hellstrom [Mon, 27 Mar 2017 11:06:05 +0000 (13:06 +0200)]
drm/vmwgfx: Remove getparam error message

commit 53e16798b0864464c5444a204e1bb93ae246c429 upstream.

The mesa winsys sometimes uses unimplemented parameter requests to
check for features. Remove the error message to avoid bloating the
kernel log.

Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Brian Paul <>
Reviewed-by: Sinclair Yeh <>
Signed-off-by: Ben Hutchings <>
5 years agodrm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl()
Murray McAllister [Mon, 27 Mar 2017 09:15:12 +0000 (11:15 +0200)]
drm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl()

commit 63774069d9527a1aeaa4aa20e929ef5e8e9ecc38 upstream.

In vmw_get_cap_3d_ioctl(), a user can supply 0 for a size that is
used in vzalloc(). This eventually calls dump_stack() (in warn_alloc()),
which can leak useful addresses to dmesg.

Add check to avoid a size of 0.

Signed-off-by: Murray McAllister <>
Reviewed-by: Sinclair Yeh <>
Signed-off-by: Ben Hutchings <>
5 years agodrm/vmwgfx: Type-check lookups of fence objects
Thomas Hellstrom [Mon, 27 Mar 2017 09:09:08 +0000 (11:09 +0200)]
drm/vmwgfx: Type-check lookups of fence objects

commit f7652afa8eadb416b23eb57dec6f158529942041 upstream.

A malicious caller could otherwise hand over handles to other objects
causing all sorts of interesting problems.

Testing done: Ran a Fedora 25 desktop using both Xorg and

Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Sinclair Yeh <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
5 years agoubi/upd: Always flush after prepared for an update
Sebastian Siewior [Wed, 22 Feb 2017 16:15:21 +0000 (17:15 +0100)]
ubi/upd: Always flush after prepared for an update

commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.

In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:

|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592

All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.

So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.

Signed-off-by: Sebastian Andrzej Siewior <>
Signed-off-by: Richard Weinberger <>
[bwh: Backported to 3.2: ubi_wl_flush() only takes 1 parameter]
Signed-off-by: Ben Hutchings <>
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 <>