6 years agosched/core: Fix a race between try_to_wake_up() and a woken up task
Balbir Singh [Mon, 5 Sep 2016 03:16:40 +0000 (13:16 +1000)]
sched/core: Fix a race between try_to_wake_up() and a woken up task

commit 135e8c9250dd5c8c9aae5984fde6f230d0cbfeaf upstream.

The origin of the issue I've seen is related to
a missing memory barrier between check for task->state and
the check for task->on_rq.

The task being woken up is already awake from a schedule()
and is doing the following:

do {
} while (!cond);

The waker, actually gets stuck doing the following in

while (p->on_cpu)


The instance I've seen involves the following race:


 while () {
   if (cond)
   do {
   } while (!cond);
   raw_spin_lock_irqsave(wait_lock)   wake_up_process()
 }   try_to_wake_up()
 set_current_state(TASK_RUNNING);   ..

CPU2 wakes up CPU1, but before it can get the wait_lock and set
current state to TASK_RUNNING the following occurs:

 if (!list_empty)
   if (p->on_rq && ttwu_wakeup())
   while (p->on_cpu)

CPU3 tries to wake up the task on CPU1 again since it finds
it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
after CPU2, CPU3 got it.

CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
the task is spinning on the wait_lock. Interestingly since p->on_rq
is checked under pi_lock, I've noticed that try_to_wake_up() finds
p->on_rq to be 0. This was the most confusing bit of the analysis,
but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
check is not reliable without this fix IMHO. The race is visible
(based on the analysis) only when ttwu_queue() does a remote wakeup
via ttwu_queue_remote. In which case the p->on_rq change is not
done uder the pi_lock.

The result is that after a while the entire system locks up on
the raw_spin_irqlock_save(wait_lock) and the holder spins infintely

Reproduction of the issue:

The issue can be reproduced after a long run on my system with 80
threads and having to tweak available memory to very low and running
memory stress-ng mmapfork test. It usually takes a long time to
reproduce. I am trying to work on a test case that can reproduce
the issue faster, but thats work in progress. I am still testing the
changes on my still in a loop and the tests seem OK thus far.

Big thanks to Benjamin and Nick for helping debug this as well.
Ben helped catch the missing barrier, Nick caught every missing
bit in my theory.

Signed-off-by: Balbir Singh <>
[ Updated comment to clarify matching barriers. Many
  architectures do not have a full barrier in switch_to()
  so that cannot be relied upon. ]
Signed-off-by: Peter Zijlstra (Intel) <>
Acked-by: Benjamin Herrenschmidt <>
Cc: Alexey Kardashevskiy <>
Cc: Linus Torvalds <>
Cc: Nicholas Piggin <>
Cc: Nicholas Piggin <>
Cc: Oleg Nesterov <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoiio: accel: kxsd9: Fix scaling bug
Linus Walleij [Thu, 1 Sep 2016 09:44:35 +0000 (11:44 +0200)]
iio: accel: kxsd9: Fix scaling bug

commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream.

All the scaling of the KXSD9 involves multiplication with a
fraction number < 1.

However the scaling value returned from IIO_INFO_SCALE was
unpredictable as only the micros of the value was assigned, and
not the integer part, resulting in scaling like this:

$cat in_accel_scale

Fix this by assigning zero to the integer part.

Tested-by: Jonathan Cameron <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Jonathan Cameron <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoIB/ipoib: Fix memory corruption in ipoib cm mode connect flow
Erez Shitrit [Sun, 28 Aug 2016 07:58:31 +0000 (10:58 +0300)]
IB/ipoib: Fix memory corruption in ipoib cm mode connect flow

commit 546481c2816ea3c061ee9d5658eb48070f69212e upstream.

When a new CM connection is being requested, ipoib driver copies data
from the path pointer in the CM/tx object, the path object might be
invalid at the point and memory corruption will happened later when now
the CM driver will try using that data.

The next scenario demonstrates it:
neigh_add_path --> ipoib_cm_create_tx -->
queue_work (pointer to path is in the cm/tx struct)
#while the work is still in the queue,
#the port goes down and causes the ipoib_flush_paths:
ipoib_flush_paths --> path_free --> kfree(path)
#at this point the work scheduled starts.
ipoib_cm_tx_start --> copy from the (invalid)path pointer:
(memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);)
 -> memory corruption.

To fix that the driver now starts the CM/tx connection only if that
specific path exists in the general paths database.
This check is protected with the relevant locks, and uses the gid from
the neigh member in the CM/tx object which is valid according to the ref
count that was taken by the CM/tx.

Fixes: 839fcaba35 ('IPoIB: Connected mode experimental support')
Signed-off-by: Erez Shitrit <>
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Doug Ledford <>
[bwh: Backported to 3.2: s/neigh->daddr/neigh->neighbour->ha/]
Signed-off-by: Ben Hutchings <>
6 years agoIB/core: Fix use after free in send_leave function
Erez Shitrit [Sun, 28 Aug 2016 07:58:30 +0000 (10:58 +0300)]
IB/core: Fix use after free in send_leave function

commit 68c6bcdd8bd00394c234b915ab9b97c74104130c upstream.

The function send_leave sets the member: group->query_id
(group->query_id = ret) after calling the sa_query, but leave_handler
can be executed before the setting and it might delete the group object,
and will get a memory corruption.

Additionally, this patch gets rid of group->query_id variable which is
not used.

Fixes: faec2f7b96b5 ('IB/sa: Track multicast join/leave requests')
Signed-off-by: Erez Shitrit <>
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agox86/paravirt: Do not trace _paravirt_ident_*() functions
Steven Rostedt [Wed, 25 May 2016 17:47:26 +0000 (13:47 -0400)]
x86/paravirt: Do not trace _paravirt_ident_*() functions

commit 15301a570754c7af60335d094dd2d1808b0641a5 upstream.

Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up
after enabling function tracer. I asked him to bisect the functions within
available_filter_functions, which he did and it came down to three:

  _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64()

It was found that this is only an issue when noreplace-paravirt is added
to the kernel command line.

This means that those functions are most likely called within critical
sections of the funtion tracer, and must not be traced.

In newer kenels _paravirt_nop() is defined within gcc asm(), and is no
longer an issue.  But both _paravirt_ident_{32,64}() causes the
following splat when they are traced:

 mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054)
 mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070)
 mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054)
 mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054)
 NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469]
 Modules linked in: e1000e
 CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
 task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000
 RIP: 0010:[<ffffffff81134148>]  [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0
 RSP: 0018:ffff8800d4aefb90  EFLAGS: 00000246
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40
 RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030
 RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000
 R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8
 R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0
 FS:  00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0
 Call Trace:
 Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b

Reported-by: Łukasz Daniluk <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: timer: fix NULL pointer dereference in read()/ioctl() race
Vegard Nossum [Sun, 28 Aug 2016 08:13:07 +0000 (10:13 +0200)]
ALSA: timer: fix NULL pointer dereference in read()/ioctl() race

commit 11749e086b2766cccf6217a527ef5c5604ba069c upstream.

I got this with syzkaller:

    BUG: KASAN: null-ptr-deref on address 0000000000000020
    Read of size 32 by task syz-executor/22519
    CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2
     0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
     ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
     ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
    Call Trace:
     [<ffffffff81f9f141>] dump_stack+0x83/0xb2
     [<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
     [<ffffffff8161ff74>] kasan_report+0x34/0x40
     [<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
     [<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
     [<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
     [<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
     [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
     [<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
     [<ffffffff8127c278>] ? do_group_exit+0x108/0x330
     [<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
     [<ffffffff81674dfe>] __vfs_read+0x10e/0x550
     [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
     [<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
     [<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
     [<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
     [<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
     [<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
     [<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
     [<ffffffff81675355>] vfs_read+0x115/0x330
     [<ffffffff81676371>] SyS_read+0xd1/0x1a0
     [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
     [<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
     [<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
     [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
     [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
     [<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
     [<ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25

There are a couple of problems that I can see:

 - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
   tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
   would get a NULL pointer dereference like the above splat

 - the same ioctl() can free tu->queue/to->tqueue which means read()
   could potentially see (and dereference) the freed pointer

We can fix both by taking the ioctl_lock mutex when dereferencing
->queue/->tqueue, since that's always held over all the ioctl() code.

Just looking at the code I find it likely that there are more problems
here such as tu->qhead pointing outside the buffer if the size is
changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.

Signed-off-by: Vegard Nossum <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: timer: fix NULL pointer dereference on memory allocation failure
Vegard Nossum [Sun, 28 Aug 2016 22:33:51 +0000 (00:33 +0200)]
ALSA: timer: fix NULL pointer dereference on memory allocation failure

commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.

I hit this with syzkaller:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
    task: ffff88011278d600 task.stack: ffff8801120c0000
    RIP: 0010:[<ffffffff82c8ba07>]  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
    RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
    RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
    RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
    R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
    R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
    FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
     ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
     ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
     ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
    Call Trace:
     [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
     [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
     [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
     [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
     [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
     [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
     [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
     [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
     [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
     [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
     [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
     [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
     [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
     [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
     [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
     [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
     [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
     [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
     [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
    RIP  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
     RSP <ffff8801120c7a60>
    ---[ end trace 5955b08db7f2b029 ]---

This can happen if snd_hrtimer_open() fails to allocate memory and
returns an error, which is currently not checked by snd_timer_open():

     - snd_timer_user_tselect()
- snd_timer_close()
   - snd_hrtimer_close()
      - (struct snd_timer *) t->private_data = NULL
        - snd_timer_open()
           - snd_hrtimer_open()
              - kzalloc() fails; t->private_data is still NULL

     - snd_timer_user_start()
- snd_timer_start()
   - snd_timer_start1()
      - snd_hrtimer_start()
- t->private_data == NULL // boom

Signed-off-by: Vegard Nossum <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: don't put_device() since snd_timer_instance_new()
 doesn't take a device reference]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE
Vegard Nossum [Sun, 28 Aug 2016 22:33:50 +0000 (00:33 +0200)]
ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE

commit 6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream.

I got this:

    divide error: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
    task: ffff8801120a9580 task.stack: ffff8801120b0000
    RIP: 0010:[<ffffffff82c8bd9a>]  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
    RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
    RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
    RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
    R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
    R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
    FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
     0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
     ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
     00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
    Call Trace:
     [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
     [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
     [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
     [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
     [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
     [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
     [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
     [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
     [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
     [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
     [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
     [<ffffffff82c87015>] snd_timer_continue+0x45/0x80
     [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
     [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
     [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
     [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
     [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
     [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
     [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
     [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
     [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
     [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
     [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
     [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
     [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
     [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
     [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
     [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
     [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
    RIP  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
     RSP <ffff88011aa87da8>
    ---[ end trace 6aa380f756a21074 ]---

The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
completely new/unused timer -- it will have ->sticks == 0, which causes a
divide by 0 in snd_hrtimer_callback().

Signed-off-by: Vegard Nossum <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agofs/seq_file: fix out-of-bounds read
Vegard Nossum [Thu, 25 Aug 2016 22:17:11 +0000 (15:17 -0700)]
fs/seq_file: fix out-of-bounds read

commit 088bf2ff5d12e2e32ee52a4024fec26e582f44d3 upstream.

seq_read() is a nasty piece of work, not to mention buggy.

It has (I think) an old bug which allows unprivileged userspace to read
beyond the end of m->buf.

I was getting these:

    BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880
    Read of size 2713 by task trinity-c2/1329
    CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
    Call Trace:
    Object at ffff880116889100, in cache kmalloc-4096 size: 4096
    PID = 1329
    PID = 0
    (stack is not available)
    Memory state around the buggy address:
     ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    Disabling lock debugging due to kernel taint

This seems to be the same thing that Dave Jones was seeing here:

There are multiple issues here:

  1) If we enter the function with a non-empty buffer, there is an attempt
     to flush it. But it was not clearing m->from after doing so, which
     means that if we try to do this flush twice in a row without any call
     to traverse() in between, we are going to be reading from the wrong
     place -- the splat above, fixed by this patch.

  2) If there's a short write to userspace because of page faults, the
     buffer may already contain multiple lines (i.e. pos has advanced by
     more than 1), but we don't save the progress that was made so the
     next call will output what we've already returned previously. Since
     that is a much less serious issue (and I have a headache after
     staring at seq_read() for the past 8 hours), I'll leave that for now.

Signed-off-by: Vegard Nossum <>
Reported-by: Dave Jones <>
Cc: Al Viro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: option: add WeTelecom 0x6802 and 0x6803 products
Aleksandr Makarov [Wed, 24 Aug 2016 10:06:22 +0000 (13:06 +0300)]
USB: serial: option: add WeTelecom 0x6802 and 0x6803 products

commit 40d9c32525cba79130612650b1abc47c0c0f19a8 upstream.

These product IDs are listed in Windows driver.
0x6803 corresponds to WeTelecom WM-D300.
0x6802 name is unknown.

Signed-off-by: Aleksandr Makarov <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agox86/apic: Do not init irq remapping if ioapic is disabled
Wanpeng Li [Tue, 23 Aug 2016 12:07:19 +0000 (20:07 +0800)]
x86/apic: Do not init irq remapping if ioapic is disabled

commit 2e63ad4bd5dd583871e6602f9d398b9322d358d9 upstream.

  -> default_setup_apic_routing
    -> enable_IR_x2apic
      -> irq_remapping_prepare
        -> intel_prepare_irq_remapping
          -> intel_setup_irq_remapping

So IR table is setup even if "noapic" boot parameter is added. As a result we
crash later when the interrupt affinity is set due to a half initialized
remapping infrastructure.

Prevent remap initialization when IOAPIC is disabled.

Signed-off-by: Wanpeng Li <>
Cc: Peter Zijlstra <>
Cc: Joerg Roedel <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoubifs: Fix assertion in layout_in_gaps()
Vincent Stehlé [Fri, 12 Aug 2016 13:26:30 +0000 (15:26 +0200)]
ubifs: Fix assertion in layout_in_gaps()

commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a upstream.

An assertion in layout_in_gaps() verifies that the gap_lebs pointer is
below the maximum bound. When computing this maximum bound the idx_lebs
count is multiplied by sizeof(int), while C pointers arithmetic does take
into account the size of the pointed elements implicitly already. Remove
the multiplication to fix the assertion.

Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Signed-off-by: Vincent Stehlé <>
Cc: Artem Bityutskiy <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Richard Weinberger <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: avoid left shift by -1
Alan Stern [Tue, 23 Aug 2016 19:32:51 +0000 (15:32 -0400)]
USB: avoid left shift by -1

commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa upstream.

UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
can occur when an URB is submitted for a bulk or control endpoint on
a high-speed device, since the code doesn't bother to check the
endpoint type; normally only interrupt or isochronous endpoints have
a nonzero bInterval value.

Aside from the fact that the operation is illegal, it shouldn't matter
because the result isn't used.  Still, in theory it could cause a
hardware exception or other problem, so we should work around it.
This patch avoids doing the left shift unless the shift amount is >= 0.

The same piece of code has another problem.  When checking the device
speed (the exponential encoding for interrupt endpoints is used only
by high-speed or faster devices), we need to look for speed >=
USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
this check.

Signed-off-by: Alan Stern <>
Reported-by: Vittorio Zecca <>
Tested-by: Vittorio Zecca <>
Suggested-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: fix typo in wMaxPacketSize validation
Alan Stern [Mon, 22 Aug 2016 20:58:53 +0000 (16:58 -0400)]
USB: fix typo in wMaxPacketSize validation

commit 6c73358c83ce870c0cf32413e5cadb3b9a39c606 upstream.

The maximum value allowed for wMaxPacketSize of a high-speed interrupt
endpoint is 1024 bytes, not 1023.

Signed-off-by: Alan Stern <>
Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agousb: gadget: fsl_qe_udc: signedness bug in qe_get_frame()
Dan Carpenter [Fri, 15 Jul 2016 11:15:47 +0000 (14:15 +0300)]
usb: gadget: fsl_qe_udc: signedness bug in qe_get_frame()

commit f4693b08cc901912a87369c46537b94ed4084ea0 upstream.

We can't assign -EINVAL to a u16.

Fixes: 3948f0e0c999 ('usb: add Freescale QE/CPM USB peripheral controller driver')
Acked-by: Peter Chen <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agodrm: Reject page_flip for !DRIVER_MODESET
Daniel Vetter [Sat, 20 Aug 2016 10:22:11 +0000 (12:22 +0200)]
drm: Reject page_flip for !DRIVER_MODESET

commit 6f00975c619064a18c23fd3aced325ae165a73b9 upstream.

Somehow this one slipped through, which means drivers without modeset
support can be oopsed (since those also don't call
drm_mode_config_init, which means the crtc lookup will chase an
uninitalized idr).

Reported-by: Alexander Potapenko <>
Cc: Alexander Potapenko <>
Signed-off-by: Daniel Vetter <>
Reviewed-by: Chris Wilson <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
6 years agoiio: accel: kxsd9: Fix raw read return
Linus Walleij [Tue, 16 Aug 2016 13:33:28 +0000 (15:33 +0200)]
iio: accel: kxsd9: Fix raw read return

commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream.

Any readings from the raw interface of the KXSD9 driver will
return an empty string, because it does not return
IIO_VAL_INT but rather some random value from the accelerometer
to the caller.

Signed-off-by: Linus Walleij <>
Signed-off-by: Jonathan Cameron <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: option: add WeTelecom WM-D200
Aleksandr Makarov [Sat, 20 Aug 2016 10:29:41 +0000 (13:29 +0300)]
USB: serial: option: add WeTelecom WM-D200

commit 6695593e4a7659db49ac6eca98c164f7b5589f72 upstream.

Add support for WeTelecom WM-D200.

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=22de ProdID=6801 Rev=00.00
S:  Manufacturer=WeTelecom Incorporated
S:  Product=WeTelecom Mobile Products
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Signed-off-by: Aleksandr Makarov <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoparisc: Fix order of EREFUSED define in errno.h
Helge Deller [Sat, 20 Aug 2016 09:51:38 +0000 (11:51 +0200)]
parisc: Fix order of EREFUSED define in errno.h

commit 3eb53b20d7bd1374598cfb1feaa081fcac0e76cd upstream.

When building gccgo in userspace, errno.h gets parsed and the go include file
sysinfo.go is generated.

Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED
is defined later on in errno.h, this leads to go complaining that EREFUSED
isn't defined yet.

Fix this trivial problem by moving the define of EREFUSED down after
ECONNREFUSED in errno.h (and clean up the indenting while touching this line).

Signed-off-by: Helge Deller <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoInput: i8042 - set up shared ps2_cmd_mutex for AUX ports
Dmitry Torokhov [Wed, 17 Aug 2016 00:38:54 +0000 (17:38 -0700)]
Input: i8042 - set up shared ps2_cmd_mutex for AUX ports

commit 47af45d684b5f3ae000ad448db02ce4f13f73273 upstream.

The commit 4097461897df ("Input: i8042 - break load dependency ...")
correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do
the same for AUX port(s), which results in communication on KBD and AUX
ports to clash with each other.

Fixes: 4097461897df ("Input: i8042 - break load dependency ...")
Reported-by: Bruno Wolff III <>
Tested-by: Bruno Wolff III <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon: fix radeon_move_blit on 32bit systems
Christian König [Wed, 17 Aug 2016 07:46:42 +0000 (09:46 +0200)]
drm/radeon: fix radeon_move_blit on 32bit systems

commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream.

This bug seems to be present for a very long time.

Signed-off-by: Christian König <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agotcp: fix use after free in tcp_xmit_retransmit_queue()
Eric Dumazet [Wed, 17 Aug 2016 12:56:26 +0000 (05:56 -0700)]
tcp: fix use after free in tcp_xmit_retransmit_queue()

commit bb1fceca22492109be12640d49f5ea5a544c6bb4 upstream.

When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()

Then it attempts to copy user data into this fresh skb.

If the copy fails, we undo the work and remove the fresh skb.

Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)

Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.

This bug was found by Marco Grassi thanks to syzkaller.

Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
Reported-by: Marco Grassi <>
Signed-off-by: Eric Dumazet <>
Cc: Ilpo Järvinen <>
Cc: Yuchung Cheng <>
Cc: Neal Cardwell <>
Acked-by: Neal Cardwell <>
Reviewed-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: don't dereference a xhci member after removing xhci
Mathias Nyman [Tue, 16 Aug 2016 07:18:06 +0000 (10:18 +0300)]
xhci: don't dereference a xhci member after removing xhci

commit f1f6d9a8b540df22b87a5bf6bc104edaade81f47 upstream.

Remove the hcd after checking for the xhci last quirks, not before.

This caused a hang on a Alpine Ridge xhci based maching which remove
the whole xhci controller when unplugging the last usb device

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agousb: xhci: Fix panic if disconnect
Jim Lin [Tue, 16 Aug 2016 07:18:05 +0000 (10:18 +0300)]
usb: xhci: Fix panic if disconnect

commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 upstream.

After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device

If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel

virt_dev = xhci->devs[slot_id];
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)

[] Unable to handle kernel paging request at virtual address 00001a68
[] pgd=ffffffc001430000
[] [00001a68] *pgd=000000013c807003, *pud=000000013c807003,
*pmd=000000013c808003, *pte=0000000000000000
[] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G     U
[] Workqueue: pm pm_runtime_work
[] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti:
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4

This issue is found when running with realtek ethernet device

Signed-off-by: Jim Lin <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agocdc-acm: fix wrong pipe type on rx interrupt xfers
Gavin Li [Fri, 12 Aug 2016 07:52:56 +0000 (00:52 -0700)]
cdc-acm: fix wrong pipe type on rx interrupt xfers

commit add125054b8727103631dce116361668436ef6a7 upstream.

This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb().

Signed-off-by: Gavin Li <>
Acked-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: mos7840: fix non-atomic allocation in write path
Alexey Khoroshilov [Thu, 11 Aug 2016 22:05:09 +0000 (01:05 +0300)]
USB: serial: mos7840: fix non-atomic allocation in write path

commit 3b7c7e52efda0d4640060de747768360ba70a7c0 upstream.

There is an allocation with GFP_KERNEL flag in mos7840_write(),
while it may be called from interrupt context.

Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
allocation in write path")

Found by Linux Driver Verification project (

Signed-off-by: Alexey Khoroshilov <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: mos7720: fix non-atomic allocation in write path
Alexey Khoroshilov [Thu, 11 Aug 2016 22:05:08 +0000 (01:05 +0300)]
USB: serial: mos7720: fix non-atomic allocation in write path

commit 5a5a1d614287a647b36dff3f40c2b0ceabbc83ec upstream.

There is an allocation with GFP_KERNEL flag in mos7720_write(),
while it may be called from interrupt context.

Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
allocation in write path")

Found by Linux Driver Verification project (

Signed-off-by: Alexey Khoroshilov <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomegaraid_sas: Fix probing cards without io port
Yinghai Lu [Sat, 6 Aug 2016 06:37:34 +0000 (23:37 -0700)]
megaraid_sas: Fix probing cards without io port

commit e7f851684efb3377e9c93aca7fae6e76212e5680 upstream.

Found one megaraid_sas HBA probe fails,

[  187.235190] scsi host2: Avago SAS based MegaRAID driver
[  191.112365] megaraid_sas 0000:89:00.0: BAR 0: can't reserve [io  0x0000-0x00ff]
[  191.120548] megaraid_sas 0000:89:00.0: IO memory region busy!

and the card has resource like,
[  125.097714] pci 0000:89:00.0: [1000:005d] type 00 class 0x010400
[  125.104446] pci 0000:89:00.0: reg 0x10: [io  0x0000-0x00ff]
[  125.110686] pci 0000:89:00.0: reg 0x14: [mem 0xce400000-0xce40ffff 64bit]
[  125.118286] pci 0000:89:00.0: reg 0x1c: [mem 0xce300000-0xce3fffff 64bit]
[  125.125891] pci 0000:89:00.0: reg 0x30: [mem 0xce200000-0xce2fffff pref]

that does not io port resource allocated from BIOS, and kernel can not
assign one as io port shortage.

The driver is only looking for MEM, and should not fail.

It turns out megasas_init_fw() etc are using bar index as mask.  index 1
is used as mask 1, so that pci_request_selected_regions() is trying to
request BAR0 instead of BAR1.

Fix all related reference.

Fixes: b6d5d8808b4c ("megaraid_sas: Use lowest memory bar for SR-IOV VF support")
Signed-off-by: Yinghai Lu <>
Acked-by: Kashyap Desai <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agoarm: oabi compat: add missing access checks
Dave Weinstein [Thu, 28 Jul 2016 18:55:41 +0000 (11:55 -0700)]
arm: oabi compat: add missing access checks

commit 7de249964f5578e67b99699c5f0b405738d820a2 upstream.

Add access checks to sys_oabi_epoll_wait() and sys_oabi_semtimedop().
This fixes CVE-2016-3857, a local privilege escalation under

Reported-by: Chiachih Wu <>
Reviewed-by: Kees Cook <>
Reviewed-by: Nicolas Pitre <>
Signed-off-by: Dave Weinstein <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agox86/mm: Disable preemption during CR3 read+write
Sebastian Andrzej Siewior [Fri, 5 Aug 2016 13:37:39 +0000 (15:37 +0200)]
x86/mm: Disable preemption during CR3 read+write

commit 5cf0791da5c162ebc14b01eb01631cfa7ed4fa6e upstream.

There's a subtle preemption race on UP kernels:

Usually current->mm (and therefore mm->pgd) stays the same during the
lifetime of a task so it does not matter if a task gets preempted during
the read and write of the CR3.

But then, there is this scenario on x86-UP:

TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by:

 -> mmput()
 -> exit_mmap()
 -> tlb_finish_mmu()
 -> tlb_flush_mmu()
 -> tlb_flush_mmu_tlbonly()
 -> tlb_flush()
 -> flush_tlb_mm_range()
 -> __flush_tlb_up()
 -> __flush_tlb()
 ->  __native_flush_tlb()

At this point current->mm is NULL but current->active_mm still points to
the "old" mm.

Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its
own mm so CR3 has changed.

Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's
mm and so CR3 remains unchanged. Once taskA gets active it continues
where it was interrupted and that means it writes its old CR3 value
back. Everything is fine because userland won't need its memory

Now the fun part:

Let's preempt taskA one more time and get back to taskB. This
time switch_mm() won't do a thing because oldmm (->active_mm)
is the same as mm (as per context_switch()). So we remain
with a bad CR3 / PGD and return to userland.

The next thing that happens is handle_mm_fault() with an address for
the execution of its code in userland. handle_mm_fault() realizes that
it has a PTE with proper rights so it returns doing nothing. But the
CPU looks at the wrong PGD and insists that something is wrong and
faults again. And again. And one more time…

This pagefault circle continues until the scheduler gets tired of it and
puts another task on the CPU. It gets little difficult if the task is a
RT task with a high priority. The system will either freeze or it gets
fixed by the software watchdog thread which usually runs at RT-max prio.
But waiting for the watchdog will increase the latency of the RT task
which is no good.

Fix this by disabling preemption across the critical code section.

Signed-off-by: Sebastian Andrzej Siewior <>
Acked-by: Peter Zijlstra (Intel) <>
Acked-by: Rik van Riel <>
Acked-by: Andy Lutomirski <>
Cc: Borislav Petkov <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Mel Gorman <>
Cc: Peter Zijlstra <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
[ Prettified the changelog. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agos390/dasd: fix hanging device after clear subchannel
Stefan Haberland [Mon, 8 Aug 2016 12:08:17 +0000 (14:08 +0200)]
s390/dasd: fix hanging device after clear subchannel

commit 9ba333dc55cbb9523553df973adb3024d223e905 upstream.

When a device is in a status where CIO has killed all I/O by itself the
interrupt for a clear request may not contain an irb to determine the
clear function. Instead it contains an error pointer -EIO.
This was ignored by the DASD int_handler leading to a hanging device
waiting for a clear interrupt.

Handle -EIO error pointer correctly for requests that are clear pending and
treat the clear as successful.

Signed-off-by: Stefan Haberland <>
Reviewed-by: Sebastian Ott <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: validate wMaxPacketValue entries in endpoint descriptors
Alan Stern [Mon, 1 Aug 2016 19:25:56 +0000 (15:25 -0400)]
USB: validate wMaxPacketValue entries in endpoint descriptors

commit aed9d65ac3278d4febd8665bd7db59ef53e825fe upstream.

Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values.  This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum

This issue was first discovered and tests were conducted by Jake Lamberson
<>, an intern working for Rosie Hall.

Signed-off-by: Alan Stern <>
Reported-by: roswest <>
Tested-by: roswest <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: drop the USB_SPEED_SUPER_PLUS case]
Signed-off-by: Ben Hutchings <>
6 years agonetfilter: nfnetlink_queue: reject verdict request from different portid
Liping Zhang [Mon, 8 Aug 2016 14:07:27 +0000 (22:07 +0800)]
netfilter: nfnetlink_queue: reject verdict request from different portid

commit 00a3101f561816e58de054a470484996f78eb5eb upstream.

Like NFQNL_MSG_VERDICT_BATCH do, we should also reject the verdict
request when the portid is not same with the initial portid(maybe
from another process).

Fixes: 97d32cf9440d ("netfilter: nfnetlink_queue: batch verdict support")
Signed-off-by: Liping Zhang <>
Reviewed-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoaacraid: Check size values after double-fetch from user
Dave Carroll [Fri, 5 Aug 2016 19:44:10 +0000 (13:44 -0600)]
aacraid: Check size values after double-fetch from user

commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 upstream.

In aacraid's ioctl_send_fib() we do two fetches from userspace, one the
get the fib header's size and one for the fib itself. Later we use the
size field from the second fetch to further process the fib. If for some
reason the size from the second fetch is different than from the first
fix, we may encounter an out-of- bounds access in aac_fib_send(). We
also check the sender size to insure it is not out of bounds. This was
reported in and was
assigned CVE-2016-6480.

Reported-by: Pengfei Wang <>
Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)'
Signed-off-by: Dave Carroll <>
Reviewed-by: Johannes Thumshirn <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/edid: Add 6 bpc quirk for display AEO model 0.
Mario Kleiner [Wed, 6 Jul 2016 10:05:44 +0000 (12:05 +0200)]
drm/edid: Add 6 bpc quirk for display AEO model 0.

commit e10aec652f31ec61d6a0b4d00d8ef8d2b66fa0fd upstream.

reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.

A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without

The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.

Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.

Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.

This patch should be backported to stable.

Signed-off-by: Mario Kleiner <>
Cc: Jani Nikula <>
Cc: Ville Syrjälä <>
Cc: Daniel Vetter <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: ftdi_sio: add device ID for WICED USB UART dev board
Sheng-Hui J. Chu [Thu, 28 Jul 2016 21:01:45 +0000 (17:01 -0400)]
USB: serial: ftdi_sio: add device ID for WICED USB UART dev board

commit ae34d12cc1e212ffcd92e069030e54dae69c832f upstream.

BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0

To support BCM920706V2_EVAL dev board for WICED development on Linux.
Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading
ftdi_sio for this board.

Signed-off-by: Sheng-Hui J. Chu <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: ftdi_sio: add PIDs for Ivium Technologies devices
Robert Deliën [Thu, 28 Jul 2016 18:52:55 +0000 (18:52 +0000)]
USB: serial: ftdi_sio: add PIDs for Ivium Technologies devices

commit 6977495c06f7f47636a076ee5a0ca571279d9697 upstream.

Ivium Technologies uses the FTDI VID with custom PIDs for their line of
electrochemical interfaces and the PalmSens they developed for PalmSens

Signed-off-by: Robert Delien <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: option: add D-Link DWM-156/A3
Lubomir Rintel [Sun, 24 Jul 2016 11:53:30 +0000 (13:53 +0200)]
USB: serial: option: add D-Link DWM-156/A3

commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 upstream.

The device has four interfaces; the three serial ports ought to be
handled by this driver:

00 Diagnostic interface serial port
01 NMEA device serial port
02 Mass storage (sd card)
03 Modem serial port

The other product ids listed in the Windows driver are present already.

Signed-off-by: Lubomir Rintel <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoblock: fix use-after-free in seq file
Vegard Nossum [Fri, 29 Jul 2016 08:40:31 +0000 (10:40 +0200)]
block: fix use-after-free in seq file

commit 77da160530dd1dc94f6ae15a981f24e5f0021e84 upstream.

I got a KASAN report of use-after-free:

    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    BUG kmalloc-32 (Not tainted): kasan: bad access detected

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [<ffffffff81d6ce81>] dump_stack+0x65/0x84
     [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
     [<ffffffff814704ff>] object_err+0x2f/0x40
     [<ffffffff814754d1>] kasan_report_error+0x221/0x520
     [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
     [<ffffffff83888161>] klist_iter_exit+0x61/0x70
     [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
     [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
     [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
     [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
     [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
     [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
     [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
     [<ffffffff814b8de6>] do_preadv+0x126/0x170
     [<ffffffff814b92ec>] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Signed-off-by: Vegard Nossum <>
Acked-by: Tejun Heo <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
6 years agohostfs: Freeing an ERR_PTR in hostfs_fill_sb_common()
Dan Carpenter [Wed, 13 Jul 2016 10:12:34 +0000 (13:12 +0300)]
hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common()

commit 8a545f185145e3c09348cd74326268ecfc6715a3 upstream.

We can't pass error pointers to kfree() or it causes an oops.

Fixes: 52b209f7b848 ('get rid of hostfs_read_inode()')
Signed-off-by: Dan Carpenter <>
Signed-off-by: Richard Weinberger <>
Signed-off-by: Ben Hutchings <>
6 years agomm/hugetlb: avoid soft lockup in set_max_huge_pages()
Jia He [Tue, 2 Aug 2016 21:02:31 +0000 (14:02 -0700)]
mm/hugetlb: avoid soft lockup in set_max_huge_pages()

commit 649920c6ab93429b94bc7c1aa7c0e8395351be32 upstream.

In powerpc servers with large memory(32TB), we watched several soft
lockups for hugepage under stress tests.

The call traces are as follows:


This patch fixes such soft lockups.  It is safe to call cond_resched()
there because it is out of spin_lock/unlock section.

Signed-off-by: Jia He <>
Reviewed-by: Naoya Horiguchi <>
Acked-by: Michal Hocko <>
Acked-by: Dave Hansen <>
Cc: Mike Kravetz <>
Cc: "Kirill A. Shutemov" <>
Cc: Paul Gortmaker <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodm flakey: error READ bios during the down_interval
Mike Snitzer [Fri, 29 Jul 2016 17:19:55 +0000 (13:19 -0400)]
dm flakey: error READ bios during the down_interval

commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.

When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval.  This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.

Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte

Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa <>
Signed-off-by: Mike Snitzer <>
[bwh: Backported to 3.2: in flakey_end_io(), keep using
 bio_submitted_while_down instead of pb->bio_submitted]
Signed-off-by: Ben Hutchings <>
6 years agoballoon: check the number of available pages in leak balloon
Konstantin Neumoin [Mon, 11 Jul 2016 12:28:59 +0000 (15:28 +0300)]
balloon: check the number of available pages in leak balloon

commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 upstream.

The balloon has a special mechanism that is subscribed to the oom
notification which leads to deflation for a fixed number of pages.
The number is always fixed even when the balloon is fully deflated.
But leak_balloon did not expect that the pages to deflate will be more
than taken, and raise a "BUG" in balloon_page_dequeue when page list
will be empty.

So, the simplest solution would be to check that the number of releases
pages is less or equal to the number taken pages.

Signed-off-by: Konstantin Neumoin <>
Signed-off-by: Denis V. Lunev <>
CC: Michael S. Tsirkin <>
Signed-off-by: Michael S. Tsirkin <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agox86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace
David Howells [Wed, 27 Jul 2016 10:42:38 +0000 (11:42 +0100)]
x86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace

commit f7d665627e103e82d34306c7d3f6f46f387c0d8b upstream.

x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than
calling sys_keyctl(). The latter will work in a lot of cases, thereby
hiding the issue.

Reported-by: Stephan Mueller <>
Tested-by: Stephan Mueller <>
Signed-off-by: David Howells <>
Cc: Andy Lutomirski <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: compat system call table is in ia32entry.S]
Signed-off-by: Ben Hutchings <>
6 years agoext4: validate that metadata blocks do not overlap superblock
Theodore Ts'o [Mon, 1 Aug 2016 04:51:02 +0000 (00:51 -0400)]
ext4: validate that metadata blocks do not overlap superblock

commit 829fa70dddadf9dd041d62b82cd7cea63943899d upstream.

A number of fuzzing failures seem to be caused by allocation bitmaps
or other metadata blocks being pointed at the superblock.

This can cause kernel BUG or WARNings once the superblock is
overwritten, so validate the group descriptor blocks to make sure this
doesn't happen.

Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agos390: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
James Hogan [Sun, 31 Jul 2016 12:11:11 +0000 (14:11 +0200)]

commit 68c5cf5a6091c2c3fabccfd42ca844d730ec24c6 upstream.

AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for s390 at all even though ARCH_DLINFO can contain one NEW_AUX_ENT when
VDSO is enabled.

This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which s390 doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to

Fixes: b020632e40c3 ("[S390] introduce vdso on s390")
Signed-off-by: James Hogan <>
Signed-off-by: Martin Schwidefsky <>
Cc: Heiko Carstens <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agotcp: consider recv buf for the initial window scale
Soheil Hassas Yeganeh [Fri, 29 Jul 2016 13:34:02 +0000 (09:34 -0400)]
tcp: consider recv buf for the initial window scale

commit f626300a3e776ccc9671b0dd94698fb3aa315966 upstream.

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh <>
Suggested-by: Neal Cardwell <>
Acked-by: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoubi: Fix race condition between ubi device creation and udev
Iosif Harutyunov [Fri, 22 Jul 2016 23:22:42 +0000 (23:22 +0000)]
ubi: Fix race condition between ubi device creation and udev

commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Signed-off-by: Iosif Harutyunov <>
[rw: massaged commit message]
Signed-off-by: Richard Weinberger <>
Signed-off-by: Ben Hutchings <>
6 years agoavr32: off by one in at32_init_pio()
Dan Carpenter [Wed, 13 Jul 2016 10:08:55 +0000 (13:08 +0300)]
avr32: off by one in at32_init_pio()

commit 55f1cf83d5cf885c75267269729805852039c834 upstream.

The pio_dev[] array has MAX_NR_PIO_DEVICES elements so the > should be

Fixes: 5f97f7f9400d ('[PATCH] avr32 architecture')
Signed-off-by: Dan Carpenter <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon: fix firmware info version checks
Alex Deucher [Wed, 27 Jul 2016 19:28:56 +0000 (15:28 -0400)]
drm/radeon: fix firmware info version checks

commit 3edc38a0facef45ee22af8afdce3737f421f36ab upstream.

Some of the checks didn't handle frev 2 tables properly.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
6 years agoKEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
David Howells [Wed, 27 Jul 2016 10:43:37 +0000 (11:43 +0100)]
KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace

commit 20f06ed9f61a185c6dabd662c310bed6189470df upstream.

MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
the issue.

Reported-by: Stephan Mueller <>
Signed-off-by: David Howells <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agoceph: Correctly return NXIO errors from ceph_llseek
Phil Turnbull [Thu, 21 Jul 2016 17:43:09 +0000 (13:43 -0400)]
ceph: Correctly return NXIO errors from ceph_llseek

commit 955818cd5b6c4b58ea574ace4573e7afa4c19c1e upstream.

ceph_llseek does not correctly return NXIO errors because the 'out' path
always returns 'offset'.

Fixes: 06222e491e66 ("fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek")
Signed-off-by: Phil Turnbull <>
Signed-off-by: Yan, Zheng <>
[bwh: Backported to 3.2:
 - We don't use vfs_setpos(); instead set ret = -EINVAL or ret = offset
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoInput: i8042 - break load dependency between atkbd/psmouse and i8042
Dmitry Torokhov [Mon, 25 Jul 2016 18:36:54 +0000 (11:36 -0700)]
Input: i8042 - break load dependency between atkbd/psmouse and i8042

commit 4097461897df91041382ff6fcd2bfa7ee6b2448c upstream.

As explained in we
have a hard load dependency between i8042 and atkbd which prevents
keyboard from working on Gen2 Hyper-V VMs.

> hyperv_keyboard invokes serio_interrupt(), which needs a valid serio
> driver like atkbd.c.  atkbd.c depends on libps2.c because it invokes
> ps2_command().  libps2.c depends on i8042.c because it invokes
> i8042_check_port_owner().  As a result, hyperv_keyboard actually
> depends on i8042.c.
> For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a
> Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m
> rather than =y, atkbd.ko can't load because i8042.ko can't load(due to
> no i8042 device emulated) and finally hyperv_keyboard can't work and
> the user can't input:
> (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y)

To break the dependency we move away from using i8042_check_port_owner()
and instead allow serio port owner specify a mutex that clients should use
to serialize PS/2 command stream.

Reported-by: Mark Laws <>
Tested-by: Mark Laws <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agol2tp: Correctly return -EBADF from pppol2tp_getname. [Tue, 26 Jul 2016 19:14:35 +0000 (15:14 -0400)]
l2tp: Correctly return -EBADF from pppol2tp_getname.

commit 4ac36a4adaf80013a60013d6f829f5863d5d0e05 upstream.

If 'tunnel' is NULL we should return -EBADF but the 'end_put_sess' path
unconditionally sets 'error' back to zero. Rework the error path so it
more closely matches pppol2tp_sendmsg.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Phil Turnbull <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agonet/irda: fix NULL pointer dereference on memory allocation failure
Vegard Nossum [Sat, 23 Jul 2016 05:43:50 +0000 (07:43 +0200)]
net/irda: fix NULL pointer dereference on memory allocation failure

commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d upstream.

I ran into this:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
    RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
    RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
    RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
    RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
    R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
    FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
     0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
     ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
     ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
    Call Trace:
     [<ffffffff82bca542>] irda_connect+0x562/0x1190
     [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
     [<ffffffff825b4489>] SyS_connect+0x9/0x10
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
    RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
     RSP <ffff880111747bb8>
    ---[ end trace 4cda2588bc055b30 ]---

The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.

Signed-off-by: Vegard Nossum <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoARM: OMAP3: hwmod data: Add sysc information for DSI
Sebastian Reichel [Fri, 24 Jun 2016 01:59:33 +0000 (03:59 +0200)]
ARM: OMAP3: hwmod data: Add sysc information for DSI

commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream.

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.

Signed-off-by: Sebastian Reichel <>
Signed-off-by: Tony Lindgren <>
Signed-off-by: Ben Hutchings <>
6 years agopps: do not crash when failed to register
Jiri Slaby [Wed, 20 Jul 2016 22:45:08 +0000 (15:45 -0700)]
pps: do not crash when failed to register

commit 368301f2fe4b07e5fb71dba3cc566bc59eb6705f upstream.

With this command sequence:

  modprobe plip
  modprobe pps_parport
  rmmod pps_parport

the partport_pps modules causes this crash:

  BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: parport_detach+0x1d/0x60 [pps_parport]
  Oops: 0000 [#1] SMP
  Call Trace:
    parport_unregister_driver+0x65/0xc0 [parport]

The sequence that builds up to this is:

 1) plip is loaded and takes the parport device for exclusive use:

    plip0: Parallel port at 0x378, using IRQ 7.

 2) pps_parport then fails to grab the device:

    pps_parport: parallel port PPS client
    parport0: cannot grant exclusive access for device pps_parport
    pps_parport: couldn't register with parport0

 3) rmmod of pps_parport is then killed because it tries to access
    pardev->name, but pardev (taken from port->cad) is NULL.

So add a check for NULL in the test there too.

Signed-off-by: Jiri Slaby <>
Acked-by: Rodolfo Giometti <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agonfs: don't create zero-length requests
Benjamin Coddington [Mon, 18 Jul 2016 14:41:57 +0000 (10:41 -0400)]
nfs: don't create zero-length requests

commit 149a4fddd0a72d526abbeac0c8deaab03559836a upstream.

NFS doesn't expect requests with wb_bytes set to zero and may make
unexpected decisions about how to handle that request at the page IO layer.
Skip request creation if we won't have any wb_bytes in the request.

Signed-off-by: Benjamin Coddington <>
Signed-off-by: Alexey Dobriyan <>
Reviewed-by: Weston Andros Adamson <>
Signed-off-by: Trond Myklebust <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: RM7000: Double locking bug in rm7k_tc_disable()
Dan Carpenter [Fri, 15 Jul 2016 11:16:44 +0000 (14:16 +0300)]
MIPS: RM7000: Double locking bug in rm7k_tc_disable()

commit 58a7e1c140f3ad61646bc0cd9a1f6a9cafc0b225 upstream.

We obviously intended to enable IRQs again at the end.

Fixes: 745aef5df1e2 ('MIPS: RM7000: Add support for tertiary cache')
Signed-off-by: Dan Carpenter <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agotty/vt/keyboard: fix OOB access in do_compute_shiftstate()
Dmitry Torokhov [Mon, 27 Jun 2016 21:12:34 +0000 (14:12 -0700)]
tty/vt/keyboard: fix OOB access in do_compute_shiftstate()

commit 510cccb5b0c8868a2b302a0ab524da7912da648b upstream.

The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
which is currently 256, whereas number of keys/buttons in input device (and
therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
out-of-bound access when we do

sym = U(key_maps[0][k]);

with large 'k'.

To fix it we should not attempt iterating beyond smaller of NR_KEYS and

Also while at it let's switch to for_each_set_bit() instead of open-coding

Reported-by: Sasha Levin <>
Reviewed-by: Guenter Roeck <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agohwmon: (adt7411) set bit 3 in CFG1 register
Michael Walle [Tue, 19 Jul 2016 14:43:26 +0000 (16:43 +0200)]
hwmon: (adt7411) set bit 3 in CFG1 register

commit b53893aae441a034bf4dbbad42fe218561d7d81f upstream.

According to the datasheet you should only write 1 to this bit. If it is
not set, at least AIN3 will return bad values on newer silicon revisions.

Fixes: d84ca5b345c2 ("hwmon: Add driver for ADT7411 voltage and temperature sensor")
Signed-off-by: Michael Walle <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: nand: fix bug writing 1 byte less than page size
Hector Palacios [Mon, 18 Jul 2016 08:39:18 +0000 (10:39 +0200)]
mtd: nand: fix bug writing 1 byte less than page size

commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 upstream.

nand_do_write_ops() determines if it is writing a partial page with the
part_pagewr = (column || writelen < (mtd->writesize - 1))

When 'writelen' is exactly 1 byte less than the NAND page size the formula
equates to zero, so the code doesn't process it as a partial write,
although it should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0xffffffff and iterating endlessly.

The bug may not be easy to reproduce in Linux since user space tools
usually force the padding or round-up the write size to a page-size
This was discovered in U-Boot where the issue can be reproduced by
writing any size that is 1 byte less than a page-size multiple.
For example, on a NAND with 2K page (0x800):
=> nand erase.part <partition>
=> nand write $loadaddr <partition> 7ff

[Editor's note: the bug was added in commit 29072b96078f, but moved
around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base
poi databuf as bounce buffer")]

Fixes: 29072b96078f ("[MTD] NAND: add subpage write support")
Signed-off-by: Hector Palacios <>
Acked-by: Boris Brezillon <>
Signed-off-by: Brian Norris <>
[bwh: Backported to 3.2: adjusted context as noted above]
Signed-off-by: Ben Hutchings <>
6 years agobrcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
Florian Fainelli [Mon, 18 Jul 2016 23:24:37 +0000 (16:24 -0700)]
brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()

commit f823a2aa8f4674c095a5413b9e3ba12d82df06f2 upstream.

wlc_phy_txpower_get_current() does a logical OR of power->flags, which
presumes that power.flags was initiliazed earlier by the caller,
unfortunately, this is not the case, so make sure we zero out the struct
tx_power before calling into wlc_phy_txpower_get_current().

Reported-by: coverity (CID 146011)
Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Florian Fainelli <>
Acked-by: Arend van Spriel <>
Signed-off-by: Kalle Valo <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agotpm: read burstcount from TPM_STS in one 32-bit transaction
Andrey Pronin [Thu, 30 Jun 2016 17:25:43 +0000 (10:25 -0700)]
tpm: read burstcount from TPM_STS in one 32-bit transaction

commit 9754d45e997000ad4021bc4606cc266bb38d876f upstream.

Some chips incorrectly support partial reads from TPM_STS register
at non-zero offsets. Read the entire 32-bits register instead of
making two 8-bit reads to support such devices and reduce the number
of bus transactions when obtaining the burstcount from TPM_STS.

Fixes: 27084efee0c3 ("tpm: driver for next generation TPM chips")
Signed-off-by: Andrey Pronin <>
Reviewed-by: Jarkko Sakkinen <>
Signed-off-by: Jarkko Sakkinen <>
[bwh: Backported to 3.2:
 - Use raw ioread32() instead of tpm_tis_read32()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agocrypto: scatterwalk - Fix test in scatterwalk_done
Herbert Xu [Tue, 12 Jul 2016 05:17:57 +0000 (13:17 +0800)]
crypto: scatterwalk - Fix test in scatterwalk_done

commit 5f070e81bee35f1b7bd1477bb223a873ff657803 upstream.

When there is more data to be processed, the current test in
scatterwalk_done may prevent us from calling pagedone even when
we should.

In particular, if we're on an SG entry spanning multiple pages
where the last page is not a full page, we will incorrectly skip
calling pagedone on the second last page.

This patch fixes this by adding a separate test for whether we've
reached the end of a page.

Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU
Amadeusz Sławiński [Thu, 14 Jul 2016 08:50:23 +0000 (10:50 +0200)]
Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.

When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.

Signed-off-by: Amadeusz Sławiński <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: option: add support for Telit LE910 PID 0x1206
Daniele Palmas [Mon, 6 Jun 2016 10:38:17 +0000 (12:38 +0200)]
USB: serial: option: add support for Telit LE910 PID 0x1206

commit 3c0415fa08548e3bc63ef741762664497ab187ed upstream.

This patch adds support for 0x1206 PID of Telit LE910.

Since the interfaces positions are the same than the ones for
0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.

Signed-off-by: Daniele Palmas <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: pmcmsp-flash: Allocating too much in init_msp_flash()
Dan Carpenter [Thu, 14 Jul 2016 10:44:56 +0000 (13:44 +0300)]
mtd: pmcmsp-flash: Allocating too much in init_msp_flash()

commit 79ad07d45743721010e766e65dc004ad249bd429 upstream.

There is a cut and paste issue here.  The bug is that we are allocating
more memory than necessary for msp_maps.  We should be allocating enough
space for a map_info struct (144 bytes) but we instead allocate enough
for an mtd_info struct (1840 bytes).  It's a small waste.

The other part of this is not harmful but when we allocated msp_flash
then we allocated enough space fro a map_info pointer instead of an
mtd_info pointer.  But since pointers are the same size it works out

Anyway, I decided to clean up all three allocations a bit to make them
a bit more consistent and clear.

Fixes: 68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings')
Signed-off-by: Dan Carpenter <>
Signed-off-by: Brian Norris <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: short-cut orphan cleanup on error
Vegard Nossum [Fri, 15 Jul 2016 03:21:35 +0000 (23:21 -0400)]
ext4: short-cut orphan cleanup on error

commit c65d5c6c81a1f27dec5f627f67840726fcd146de upstream.

If we encounter a filesystem error during orphan cleanup, we should stop.
Otherwise, we may end up in an infinite loop where the same inode is
processed again and again.

    EXT4-fs (loop0): warning: checktime reached, running e2fsck is recommended
    EXT4-fs error (device loop0): ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor inconsistent: 6117 vs 0 free clusters
    Aborting journal on device loop0-8.
    EXT4-fs (loop0): Remounting filesystem read-only
    EXT4-fs error (device loop0) in ext4_free_blocks:4895: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs error (device loop0) in ext4_ext_remove_space:3068: IO failure
    EXT4-fs error (device loop0) in ext4_ext_truncate:4667: Journal has aborted
    EXT4-fs error (device loop0) in ext4_orphan_del:2927: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs (loop0): Inode 16 (00000000618192a0): orphan list check failed!
    EXT4-fs (loop0): Inode 16 (0000000061819748): orphan list check failed!
    EXT4-fs (loop0): Inode 16 (0000000061819bf0): orphan list check failed!

See-also: c9eb13a9105 ("ext4: fix hang when processing corrupted orphaned inode list")
Cc: Jan Kara <>
Signed-off-by: Vegard Nossum <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: fix reference counting bug on block allocation error
Vegard Nossum [Fri, 15 Jul 2016 03:02:47 +0000 (23:02 -0400)]
ext4: fix reference counting bug on block allocation error

commit 554a5ccc4e4a20c5f3ec859de0842db4b4b9c77e upstream.

If we hit this error when mounted with errors=continue or

    EXT4-fs error (device loop0): ext4_mb_mark_diskspace_used:2940: comm ext4.exe: Allocating blocks 5090-6081 which overlap fs metadata

then ext4_mb_new_blocks() will call ext4_mb_release_context() and try to
continue. However, ext4_mb_release_context() is the wrong thing to call
here since we are still actually using the allocation context.

Instead, just error out. We could retry the allocation, but there is a
possibility of getting stuck in an infinite loop instead, so this seems

[ Fixed up so we don't return EAGAIN to userspace. --tytso ]

Fixes: 8556e8f3b6 ("ext4: Don't allow new groups to be added during block allocation")
Signed-off-by: Vegard Nossum <>
Signed-off-by: Theodore Ts'o <>
Cc: Aneesh Kumar K.V <>
[bwh: Backported to 3.2:
 - Use EIO instead of EFSCORRUPTED
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: nVMX: Fix memory corruption when using VMCS shadowing
Jim Mattson [Fri, 8 Jul 2016 22:36:06 +0000 (15:36 -0700)]
KVM: nVMX: Fix memory corruption when using VMCS shadowing

commit 2f1fe81123f59271bddda673b60116bde9660385 upstream.

When freeing the nested resources of a vcpu, there is an assumption that
the vcpu's vmcs01 is the current VMCS on the CPU that executes
nested_release_vmcs12(). If this assumption is violated, the vcpu's
vmcs01 may be made active on multiple CPUs at the same time, in
violation of Intel's specification. Moreover, since the vcpu's vmcs01 is
not VMCLEARed on every CPU on which it is active, it can linger in a
CPU's VMCS cache after it has been freed and potentially
repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity
miss can result in memory corruption.

It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If
the vcpu in question was last loaded on a different CPU, it must be
migrated to the current CPU before calling vmx_load_vmcs01().

Signed-off-by: Jim Mattson <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: vcpu_load() returns void]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: nVMX: fix lifetime issues for vmcs02
Paolo Bonzini [Thu, 17 Jul 2014 10:25:16 +0000 (12:25 +0200)]
KVM: nVMX: fix lifetime issues for vmcs02

commit 4fa7734c62cdd8c07edd54fa5a5e91482273071a upstream.

free_nested needs the loaded_vmcs to be valid if it is a vmcs02, in
order to detach it from the shadow vmcs.  However, this is not
available anymore after commit 26a865f4aa8e (KVM: VMX: fix use after
free of vmx->loaded_vmcs, 2014-01-03).

Revert that patch, and fix its problem by forcing a vmcs01 as the
active VMCS before freeing all the nested VMX state.

Reported-by: Wanpeng Li <>
Tested-by: Wanpeng Li <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
6 years agonet: ethoc: Fix early error paths
Florian Fainelli [Tue, 12 Jul 2016 23:04:35 +0000 (16:04 -0700)]
net: ethoc: Fix early error paths

commit 386512d18b268c6182903239f9f3390f03ce4c7b upstream.

In case any operation fails before we can successfully go the point
where we would register a MDIO bus, we would be going to an error label
which involves unregistering then freeing this yet to be created MDIO
bus. Update all error paths to go to label free which is the only one
valid until either the clock is enabled, or the MDIO bus is allocated
and registered. This fixes kernel oops observed while trying to
dereference the MDIO bus structure which is not yet allocated.

Fixes: a1702857724f ("net: Add support for the OpenCores 10/100 Mbps Ethernet MAC.")
Signed-off-by: Florian Fainelli <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: Add support of 13d3:3490 AR3012 device
Dmitry Tunin [Mon, 11 Jul 2016 22:35:18 +0000 (01:35 +0300)]
Bluetooth: Add support of 13d3:3490 AR3012 device

commit 12d868964f7352e8b18e755488f7265a93431de1 upstream.

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

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: Add USB ID 13D3:3487 to ath3k
Lauro Costa [Mon, 9 May 2016 20:36:11 +0000 (17:36 -0300)]
Bluetooth: Add USB ID 13D3:3487 to ath3k

commit 72f9f8b58bc743e6b6abdc68f60db98486c3ffcf upstream.

Add hw id to ath3k usb device list and btusb blacklist

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

Requires these firmwares:
ar3k/AthrBT_0x11020100.dfu and ar3k/ramps_0x11020100_40.dfu
Firmwares are available in linux-firmware.

Device found in a laptop ASUS model N552VW. It's an Atheros AR9462 chip.

Signed-off-by: Lauro Costa <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoNFS: Don't drop CB requests with invalid principals
Chuck Lever [Wed, 29 Jun 2016 17:55:22 +0000 (13:55 -0400)]
NFS: Don't drop CB requests with invalid principals

commit a4e187d83d88eeaba6252aac0a2ffe5eaa73a818 upstream.

Before commit 778be232a207 ("NFS do not find client in NFSv4
pg_authenticate"), the Linux callback server replied with
RPC_AUTH_ERROR / RPC_AUTH_BADCRED, instead of dropping the CB
request. Let's restore that behavior so the server has a chance to
do something useful about it, and provide a warning that helps
admins correct the problem.

Fixes: 778be232a207 ("NFS do not find client in NFSv4 ...")
Signed-off-by: Chuck Lever <>
Tested-by: Steve Wise <>
Signed-off-by: Anna Schumaker <>
Signed-off-by: Ben Hutchings <>
6 years agosvc: Avoid garbage replies when pc_func() returns rpc_drop_reply
Chuck Lever [Wed, 29 Jun 2016 17:55:14 +0000 (13:55 -0400)]
svc: Avoid garbage replies when pc_func() returns rpc_drop_reply

commit 0533b13072f4bf35738290d2cf9e299c7bc6c42a upstream.

If an RPC program does not set vs_dispatch and pc_func() returns
rpc_drop_reply, the server sends a reply anyway containing a single
word containing the value RPC_DROP_REPLY (in network byte-order, of
course). This is a nonsense RPC message.

Fixes: 9e701c610923 ("svcrpc: simpler request dropping")
Signed-off-by: Chuck Lever <>
Tested-by: Steve Wise <>
Signed-off-by: Anna Schumaker <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agox86/quirks: Add early quirk to reset Apple AirPort card
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Add early quirk to reset Apple AirPort card

commit abb2bafd295fe962bbadc329dbfb2146457283ac upstream.

The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:

This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback
towards finding the best solution to this problem.

The following should be a comprehensive list of affected models:
    iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
    iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
    Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
    Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]

For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):

    irq 17: nobody cared (try booting with the "irqpoll" option)
    [<ffffffff81374370>] pcie_isr
    [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci]
    [<ffffffffc0a0b960>] azx_interrupt [snd_hda_codec]
    Disabling IRQ #17

Tested-by: Konstantin Simanov <> # [MacBookPro8,1]
Tested-by: Lukas Wunner <> # [MacBookPro9,1]
Tested-by: Bryan Paradis <> # [MacBookPro9,2]
Tested-by: Andrew Worsley <> # [MacBookPro10,1]
Tested-by: Chris Bainbridge <> # [MacBookPro10,2]
Signed-off-by: Lukas Wunner <>
Acked-by: Rafał Miłecki <>
Acked-by: Matt Fleming <>
Cc: Andy Lutomirski <>
Cc: Bjorn Helgaas <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Chris Milsted <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Matthew Garrett <>
Cc: Michael Buesch <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Yinghai Lu <>
[ Did minor readability edits. ]
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - early_ioremap() is declared in <asm/io.h> not <asm/early_ioremap.h>
 - Add definition of BCMA_RESET_ST
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agox86/quirks: Reintroduce scanning of secondary buses
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Reintroduce scanning of secondary buses

commit 850c321027c2e31d0afc71588974719a4b565550 upstream.

We used to scan secondary buses until the following commit that
was applied in 2009:

  8659c406ade3 ("x86: only scan the root bus in early PCI quirks")

which commit constrained early quirks to the root bus only. Its
motivation was to prevent application of the nvidia_bugs quirk
on secondary buses.

We're about to add a quirk to reset the Broadcom 4331 wireless card on
2011/2012 Macs, which is located on a secondary bus behind a PCIe root
port. To facilitate that, reintroduce scanning of secondary buses.

The commit message of 8659c406ade3 notes that scanning only the root bus
"saves quite some unnecessary scanning work". The algorithm used prior
to 8659c406ade3 was particularly time consuming because it scanned
buses 0 to 31 brute force. To avoid lengthening boot time, employ a
recursive strategy which only scans buses that are actually reachable
from the root bus.

Yinghai Lu pointed out that the secondary bus number read from a
bridge's config space may be invalid, in particular a value of 0 would
cause an infinite loop. The PCI core goes beyond that and recurses to a
child bus only if its bus number is greater than the parent bus number
(see pci_scan_bridge()). Since the root bus is numbered 0, this implies
that secondary buses may not be 0. Do the same on early scanning.

If this algorithm is found to significantly impact boot time or cause
infinite loops on broken hardware, it would be possible to limit its
recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
at depth 0, so the bus need not be scanned deeper than that for now. An
alternative approach would be to revert to scanning only the root bus,
and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
and 8086:1e16. Apple always positioned the card behind either of these
three ports. The quirk would then check presence of the card in slot 0
below the root port and do its deed.

Signed-off-by: Lukas Wunner <>
Cc: Andy Lutomirski <>
Cc: Bjorn Helgaas <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Yinghai Lu <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agox86/quirks: Apply nvidia_bugs quirk only on root bus
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Apply nvidia_bugs quirk only on root bus

commit 447d29d1d3aed839e74c2401ef63387780ac51ed upstream.

Since the following commit:

  8659c406ade3 ("x86: only scan the root bus in early PCI quirks")

... early quirks are only applied to devices on the root bus.

The motivation was to prevent application of the nvidia_bugs quirk on
secondary buses.

We're about to reintroduce scanning of secondary buses for a quirk to
reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
regressions, open code the requirement to apply nvidia_bugs only on the
root bus.

Signed-off-by: Lukas Wunner <>
Cc: Andy Lutomirski <>
Cc: Bjorn Helgaas <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Yinghai Lu <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agoppp: defer netns reference release for ppp channel
WANG Cong [Wed, 6 Jul 2016 05:12:36 +0000 (22:12 -0700)]
ppp: defer netns reference release for ppp channel

commit 205e1e255c479f3fd77446415706463b282f94e4 upstream.

Matt reported that we have a NULL pointer dereference
in ppp_pernet() from ppp_connect_channel(),
i.e. pch->chan_net is NULL.

This is due to that a parallel ppp_unregister_channel()
could happen while we are in ppp_connect_channel(), during
which pch->chan_net set to NULL. Since we need a reference
to net per channel, it makes sense to sync the refcnt
with the life time of the channel, therefore we should
release this reference when we destroy it.

Fixes: 1f461dcdd296 ("ppp: take reference on channels netns")
Reported-by: Matt Bennett <>
Cc: Paul Mackerras <>
Cc: Guillaume Nault <>
Cc: Cyrill Gorcunov <>
Signed-off-by: Cong Wang <>
Reviewed-by: Cyrill Gorcunov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: ctl: Stop notification after disconnection
Takashi Iwai [Fri, 8 Jul 2016 06:05:19 +0000 (08:05 +0200)]
ALSA: ctl: Stop notification after disconnection

commit f388cdcdd160687c6650833f286b9c89c50960ff upstream.

snd_ctl_remove() has a notification for the removal event.  It's
superfluous when done during the device got disconnected.  Although
the notification itself is mostly harmless, it may potentially be
harmful, and should be suppressed.  Actually some components PCM may
free ctl elements during the disconnect or free callbacks, thus it's
no theoretical issue.

This patch adds the check of card->shutdown flag for avoiding
unnecessary notifications after (or during) the disconnect.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon: Poll for both connect/disconnect on analog connectors
Lyude [Fri, 24 Jun 2016 21:54:31 +0000 (17:54 -0400)]
drm/radeon: Poll for both connect/disconnect on analog connectors

commit 14ff8d48f2235295dfb3117693008e367b49cdb5 upstream.

DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.

Easy way to reproduce:
 - Grab a machine with a radeon GPU and a VGA port
 - Plug a monitor into the VGA port, wait for it to update the connector
   from disconnected to connected
 - Disconnect the monitor on VGA, a hotplug event is never sent for the
   removal of the connector.

Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.

Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.

Signed-off-by: Lyude <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: validate s_reserved_gdt_blocks on mount
Theodore Ts'o [Wed, 6 Jul 2016 00:01:52 +0000 (20:01 -0400)]
ext4: validate s_reserved_gdt_blocks on mount

commit 5b9554dc5bf008ae7f68a52e3d7e76c0920938a2 upstream.

If s_reserved_gdt_blocks is extremely large, it's possible for
ext4_init_block_bitmap(), which is called when ext4 sets up an
uninitialized block bitmap, to corrupt random kernel memory.  Add the
same checks which e2fsck has --- it must never be larger than
blocksize / sizeof(__u32) --- and then add a backup check in
ext4_init_block_bitmap() in case the superblock gets modified after
the file system is mounted.

Reported-by: Vegard Nossum <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - Drop the second check in ext4_init_block_bitmap() since it can't return
   an error code
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoext4: don't call ext4_should_journal_data() on the journal inode
Vegard Nossum [Mon, 4 Jul 2016 15:03:00 +0000 (11:03 -0400)]
ext4: don't call ext4_should_journal_data() on the journal inode

commit 6a7fd522a7c94cdef0a3b08acf8e6702056e635c upstream.

If ext4_fill_super() fails early, it's possible for ext4_evict_inode()
to call ext4_should_journal_data() before superblock options and flags
are fully set up.  In that case, the iput() on the journal inode can
end up causing a BUG().

Work around this problem by reordering the tests so we only call
ext4_should_journal_data() after we know it's not the journal inode.

Fixes: 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data")
Fixes: 2b405bfa84 ("ext4: fix data=journal fast mount/umount hang")
Cc: Jan Kara <>
Signed-off-by: Vegard Nossum <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: check for extents that wrap around
Vegard Nossum [Thu, 30 Jun 2016 15:53:46 +0000 (11:53 -0400)]
ext4: check for extents that wrap around

commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 upstream.

An extent with lblock = 4294967295 and len = 1 will pass the
ext4_valid_extent() test:

ext4_lblk_t last = lblock + len - 1;

if (len == 0 || lblock > last)
return 0;

since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger
the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end().

We can simplify it by removing the - 1 altogether and changing the test
to use lblock + len <= lblock, since now if len = 0, then lblock + 0 ==
lblock and it fails, and if len > 0 then lblock + len > lblock in order
to pass (i.e. it doesn't overflow).

Fixes: 5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
Fixes: 2f974865f ("ext4: check for zero length extent explicitly")
Cc: Eryu Guan <>
Signed-off-by: Phil Turnbull <>
Signed-off-by: Vegard Nossum <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: xpad - validate USB endpoint count during probe
Cameron Gutman [Wed, 29 Jun 2016 16:51:35 +0000 (09:51 -0700)]
Input: xpad - validate USB endpoint count during probe

commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream.

This prevents a malicious USB device from causing an oops.

Signed-off-by: Cameron Gutman <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agousb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()
Yoshihiro Shimoda [Wed, 8 Jun 2016 07:32:50 +0000 (16:32 +0900)]
usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()

commit 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 upstream.

This patch fixes an issue that the CFIFOSEL register value is possible
to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer
using CFIFO may not work correctly.

For example:
 # modprobe g_multi file=usb-storage.bin
 # ifconfig usb0 up
 (During the USB host is sending file to the mass storage)
 # ifconfig usb0 down

In this case, since the u_ether.c may call usb_ep_enable() in
eth_stop(), if the renesas_usbhs driver is also using CFIFO for
mass storage, the mass storage may not work correctly.

So, this patch adds usbhs_lock() and usbhs_unlock() calling in
usbhsg_ep_enable() to protect CFIFOSEL register. This is because:
 - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration
 - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock()

Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
6 years agousb: renesas_usbhs: fix NULL pointer dereference in xfer_work()
Yoshihiro Shimoda [Wed, 8 Jun 2016 07:32:49 +0000 (16:32 +0900)]
usb: renesas_usbhs: fix NULL pointer dereference in xfer_work()

commit 4fdef698383db07d829da567e0e405fc41ff3a89 upstream.

This patch fixes an issue that the xfer_work() is possible to cause
NULL pointer dereference if the usb cable is disconnected while data
transfer is running.

In such case, a gadget driver may call usb_ep_disable()) before
xfer_work() is actually called. In this case, the usbhs_pkt_pop()
will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo()
in xfer_work() will return NULL.

Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoserial: samsung: Fix possible out of bounds access on non-DT platform
Krzysztof Kozlowski [Thu, 16 Jun 2016 06:27:36 +0000 (08:27 +0200)]
serial: samsung: Fix possible out of bounds access on non-DT platform

commit 926b7b5122c96e1f18cd20e85a286c7ec8d18c97 upstream.

On non-DeviceTree platforms, the index of serial device is a static
variable incremented on each probe.  It is incremented even if deferred
probe happens when getting the clock in s3c24xx_serial_init_port().

This index is used for referencing elements of statically allocated
s3c24xx_serial_ports array.  In case of re-probe, the index will point
outside of this array leading to memory corruption.

Increment the index only on successful probe.

Reported-by: Bartlomiej Zolnierkiewicz <>
Fixes: b497549a035c ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers")
Signed-off-by: Krzysztof Kozlowski <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agocrypto: gcm - Filter out async ghash if necessary
Herbert Xu [Wed, 15 Jun 2016 14:27:05 +0000 (22:27 +0800)]
crypto: gcm - Filter out async ghash if necessary

commit b30bdfa86431afbafe15284a3ad5ac19b49b88e3 upstream.

As it is if you ask for a sync gcm you may actually end up with
an async one because it does not filter out async implementations
of ghash.

This patch fixes this by adding the necessary filter when looking
for ghash.

Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agosched/cputime: Fix prev steal time accouting during CPU hotplug
Wanpeng Li [Mon, 13 Jun 2016 10:32:45 +0000 (18:32 +0800)]
sched/cputime: Fix prev steal time accouting during CPU hotplug

commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream.


  e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")

... set rq->prev_* to 0 after a CPU hotplug comes back, in order to
fix the case where (after CPU hotplug) steal time is smaller than

However, this should never happen. Steal time was only smaller because of the
KVM-specific bug fixed by the previous patch.  Worse, the previous patch
triggers a bug on CPU hot-unplug/plug operation: because
rq->prev_steal_time is cleared, all of the CPU's past steal time will be
accounted again on hot-plug.

Since the root cause has been fixed, we can just revert commit e9532e69b8d1.

Signed-off-by: Wanpeng Li <>
Signed-off-by: Peter Zijlstra (Intel) <>
Acked-by: Paolo Bonzini <>
Cc: Frederic Weisbecker <>
Cc: Linus Torvalds <>
Cc: Mike Galbraith <>
Cc: Peter Zijlstra <>
Cc: Radim Krčmář <>
Cc: Rik van Riel <>
Cc: Thomas Gleixner <>
Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")'
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/numa: Fix multiple bugs in memory_hotplug_max()
Bharata B Rao [Thu, 12 May 2016 13:34:15 +0000 (19:04 +0530)]
powerpc/numa: Fix multiple bugs in memory_hotplug_max()

commit 45b64ee64970dee9392229302efe1d1567e8d304 upstream.

memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:

1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
  all the LMBs of the guest, but that is not true for PowerKVM which
  populates only DR LMBs (LMBs that can be hotplugged/removed) in that
2 hot_add_drconf_memory_max() multiplies lmb-size with lmb-count to arrive
  at the max possible address. Since ibm,dynamic-memory doesn't include
  RMA LMBs, the address thus obtained will be less than the actual max
  address. For example, if max possible memory size is 32G, with lmb-size
  of 256MB there can be 127 LMBs in ibm,dynamic-memory (1 LMB for RMA
  which won't be present here).  hot_add_drconf_memory_max() would then
  return the max addressable memory as 127 * 256MB = 31.75GB, the max
  address should have been 32G which is what ibm,lrdr-capacity shows.
3 In PowerKVM, there can be a gap between the end of boot time RAM and
  beginning of hotplug RAM area. So just multiplying lmb-count with
  lmb-size will not provide the correct max possible address for PowerKVM.

This patch fixes 1 by using ibm,lrdr-capacity property to return the max
addressable memory whenever the property is present. Then it fixes 2 & 3
by fetching the address of the last LMB in ibm,dynamic-memory property.

Fixes: cd34206e949b ("powerpc: Add memory_hotplug_max()")
Signed-off-by: Bharata B Rao <>
Reviewed-by: David Gibson <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonetlabel: add address family checks to netlbl_{sock,req}_delattr()
Paul Moore [Mon, 6 Jun 2016 19:17:20 +0000 (15:17 -0400)]
netlabel: add address family checks to netlbl_{sock,req}_delattr()

commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 upstream.

It seems risky to always rely on the caller to ensure the socket's
address family is correct before passing it to the NetLabel kAPI,
especially since we see at least one LSM which didn't. Add address
family checks to the *_delattr() functions to help prevent future

Reported-by: Maninder Singh <>
Signed-off-by: Paul Moore <>
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.83 v3.2.83
Ben Hutchings [Thu, 20 Oct 2016 22:41:00 +0000 (23:41 +0100)]
Linux 3.2.83

6 years agomm, gup: close FOLL MAP_PRIVATE race
Michal Hocko [Sun, 16 Oct 2016 09:55:00 +0000 (11:55 +0200)]
mm, gup: close FOLL MAP_PRIVATE race

commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.

faultin_page drops FOLL_WRITE after the page fault handler did the CoW
and then we retry follow_page_mask to get our CoWed page. This is racy,
however because the page might have been unmapped by that time and so
we would have to do a page fault again, this time without CoW. This
would cause the page cache corruption for FOLL_FORCE on MAP_PRIVATE
read only mappings with obvious consequences.

This is an ancient bug that was actually already fixed once by Linus
eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race
for write access") but that was then undone due to problems on s390
by commit f33ea7f404e5 ("fix get_user_pages bug") because s390 didn't
have proper dirty pte tracking until abf09bed3cce ("s390/mm: implement
software dirty bits"). This wasn't a problem at the time as pointed out
by Hugh Dickins because madvise relied on mmap_sem for write up until
0a27a14a6292 ("mm: madvise avoid exclusive mmap_sem") but since then we
can race with madvise which can unmap the fresh COWed page or with KSM
and corrupt the content of the shared page.

This patch is based on the Linus' approach to not clear FOLL_WRITE after
the CoW page fault (aka VM_FAULT_WRITE) but instead introduces FOLL_COW
to note this fact. The flag is then rechecked during follow_pfn_pte to
enforce the page fault again if we do not see the CoWed page. Linus was
suggesting to check pte_dirty again as s390 is OK now. But that would
make backporting to some old kernels harder. So instead let's just make
sure that vm_normal_page sees a pure anonymous page.

This would guarantee we are seeing a real CoW page. Introduce
can_follow_write_pte which checks both pte_write and falls back to
PageAnon on forced write faults which passed CoW already. Thanks to Hugh
to point out that a special care has to be taken for KSM pages because
our COWed page might have been merged with a KSM one and keep its
PageAnon flag.

Fixes: 0a27a14a6292 ("mm: madvise avoid exclusive mmap_sem")
Reported-by: Phil "not Paul" Oester <>
Disclosed-by: Andy Lutomirski <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Michal Hocko <>
[bwh: Backported to 3.2:
 - Adjust filename, context, indentation
 - The 'no_page' exit path in follow_page() is different, so open-code the
 - Delete a now-unused label]
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.82 v3.2.82
Ben Hutchings [Mon, 22 Aug 2016 21:37:20 +0000 (22:37 +0100)]
Linux 3.2.82

6 years agoaudit: fix a double fetch in audit_log_single_execve_arg()
Paul Moore [Tue, 19 Jul 2016 21:42:57 +0000 (17:42 -0400)]
audit: fix a double fetch in audit_log_single_execve_arg()

commit 43761473c254b45883a64441dd0bc85a42f3645c upstream.

There is a double fetch problem in audit_log_single_execve_arg()
where we first check the execve(2) argumnets for any "bad" characters
which would require hex encoding and then re-fetch the arguments for
logging in the audit record[1].  Of course this leaves a window of
opportunity for an unsavory application to munge with the data.

This patch reworks things by only fetching the argument data once[2]
into a buffer where it is scanned and logged into the audit
records(s).  In addition to fixing the double fetch, this patch
improves on the original code in a few other ways: better handling
of large arguments which require encoding, stricter record length
checking, and some performance improvements (completely unverified,
but we got rid of some strlen() calls, that's got to be a good

As part of the development of this patch, I've also created a basic
regression test for the audit-testsuite, the test can be tracked on
GitHub at the following link:


[1] If you pay careful attention, there is actually a triple fetch
problem due to a strnlen_user() call at the top of the function.

[2] This is a tiny white lie, we do make a call to strnlen_user()
prior to fetching the argument data.  I don't like it, but due to the
way the audit record is structured we really have no choice unless we
copy the entire argument at once (which would require a rather
wasteful allocation).  The good news is that with this patch the
kernel no longer relies on this strnlen_user() value for anything
beyond recording it in the log, we also update it with a trustworthy
value whenever possible.

Reported-by: Pengfei Wang <>
Signed-off-by: Paul Moore <>
[bwh: Backported to 3.2:
 - In audit_log_execve_info() various information is retrieved via
   the extra parameter struct audit_aux_data_execve *axi
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agotcp: make challenge acks less predictable
Eric Dumazet [Sun, 10 Jul 2016 08:04:02 +0000 (10:04 +0200)]
tcp: make challenge acks less predictable

commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 upstream.

Yue Cao claims that current host rate limiting of challenge ACKS
(RFC 5961) could leak enough information to allow a patient attacker
to hijack TCP sessions. He will soon provide details in an academic

This patch increases the default limit from 100 to 1000, and adds
some randomization so that the attacker can no longer hijack
sessions without spending a considerable amount of probes.

Based on initial analysis and patch from Linus.

Note that we also have per socket rate limiting, so it is tempting
to remove the host limit in the future.

v2: randomize the count of challenge acks per second, not the period.

Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2")
Reported-by: Yue Cao <>
Signed-off-by: Eric Dumazet <>
Suggested-by: Linus Torvalds <>
Cc: Yuchung Cheng <>
Cc: Neal Cardwell <>
Acked-by: Neal Cardwell <>
Acked-by: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
 - Open-code prandom_u32_max()]
Signed-off-by: Ben Hutchings <>
6 years agords: fix an infoleak in rds_inc_info_copy
Kangjie Lu [Thu, 2 Jun 2016 08:11:20 +0000 (04:11 -0400)]
rds: fix an infoleak in rds_inc_info_copy

commit 4116def2337991b39919f3b448326e21c40e0dbb upstream.

The last field "flags" of object "minfo" is not initialized.
Copying this object out may leak kernel stack data.
Assign 0 to it to avoid leak.

Signed-off-by: Kangjie Lu <>
Acked-by: Santosh Shilimkar <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>