1. 13 Jun, 2017 36 commits
    • Vlad Tsyrklevich's avatar
      vfio/pci: Fix integer overflows, bitmask check · 073e9973
      Vlad Tsyrklevich authored
      [ Upstream commit 05692d70 ]
      
      The VFIO_DEVICE_SET_IRQS ioctl did not sufficiently sanitize
      user-supplied integers, potentially allowing memory corruption. This
      patch adds appropriate integer overflow checks, checks the range bounds
      for VFIO_IRQ_SET_DATA_NONE, and also verifies that only single element
      in the VFIO_IRQ_SET_DATA_TYPE_MASK bitmask is set.
      VFIO_IRQ_SET_ACTION_TYPE_MASK is already correctly checked later in
      vfio_pci_set_irqs_ioctl().
      
      Furthermore, a kzalloc is changed to a kcalloc because the use of a
      kzalloc with an integer multiplication allowed an integer overflow
      condition to be reached without this patch. kcalloc checks for overflow
      and should prevent a similar occurrence.
      Signed-off-by: default avatarVlad Tsyrklevich <vlad@tsyrklevich.net>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      073e9973
    • Mauro Carvalho Chehab's avatar
      [media] xc2028: avoid use after free · e21b00fe
      Mauro Carvalho Chehab authored
      [ Upstream commit 8dfbcc43 ]
      
      If struct xc2028_config is passed without a firmware name,
      the following trouble may happen:
      
      [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
      [11009.907491] ==================================================================
      [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
      [11009.907992] Read of size 1 by task modprobe/28992
      [11009.907994] =============================================================================
      [11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
      [11009.907999] -----------------------------------------------------------------------------
      
      [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
      [11009.908012] 	___slab_alloc+0x581/0x5b0
      [11009.908014] 	__slab_alloc+0x51/0x90
      [11009.908017] 	__kmalloc+0x27b/0x350
      [11009.908022] 	xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
      [11009.908026] 	usb_hcd_submit_urb+0x1e8/0x1c60
      [11009.908029] 	usb_submit_urb+0xb0e/0x1200
      [11009.908032] 	usb_serial_generic_write_start+0xb6/0x4c0
      [11009.908035] 	usb_serial_generic_write+0x92/0xc0
      [11009.908039] 	usb_console_write+0x38a/0x560
      [11009.908045] 	call_console_drivers.constprop.14+0x1ee/0x2c0
      [11009.908051] 	console_unlock+0x40d/0x900
      [11009.908056] 	vprintk_emit+0x4b4/0x830
      [11009.908061] 	vprintk_default+0x1f/0x30
      [11009.908064] 	printk+0x99/0xb5
      [11009.908067] 	kasan_report_error+0x10a/0x550
      [11009.908070] 	__asan_report_load1_noabort+0x43/0x50
      [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
      [11009.908077] 	__slab_free+0x2ec/0x460
      [11009.908080] 	kfree+0x266/0x280
      [11009.908083] 	xc2028_set_config+0x90/0x630 [tuner_xc2028]
      [11009.908086] 	xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908090] 	em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908094] 	em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908098] 	em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908101] 	em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908105] 	em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908108] 	do_one_initcall+0x141/0x300
      [11009.908111] 	do_init_module+0x1d0/0x5ad
      [11009.908114] 	load_module+0x6666/0x9ba0
      [11009.908117] 	SyS_finit_module+0x108/0x130
      [11009.908120] 	entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
      [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001
      
      [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
      [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
      [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
      [11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
      [11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
      [11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
      [11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
      [11009.908158] Call Trace:
      [11009.908162]  [<ffffffff81932007>] dump_stack+0x4b/0x64
      [11009.908165]  [<ffffffff81556759>] print_trailer+0xf9/0x150
      [11009.908168]  [<ffffffff8155ccb4>] object_err+0x34/0x40
      [11009.908171]  [<ffffffff8155f260>] kasan_report_error+0x230/0x550
      [11009.908175]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908179]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908182]  [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50
      [11009.908185]  [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0
      [11009.908189]  [<ffffffff8194cea6>] ? strcmp+0x96/0xb0
      [11009.908192]  [<ffffffff8194cea6>] strcmp+0x96/0xb0
      [11009.908196]  [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
      [11009.908200]  [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908203]  [<ffffffff8155ea78>] ? memset+0x28/0x30
      [11009.908206]  [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
      [11009.908211]  [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908215]  [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
      [11009.908219]  [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
      [11009.908222]  [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
      [11009.908226]  [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
      [11009.908230]  [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10
      [11009.908233]  [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80
      [11009.908238]  [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908242]  [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
      [11009.908245]  [<ffffffff8195222d>] ? string+0x14d/0x1f0
      [11009.908249]  [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0
      [11009.908253]  [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0
      [11009.908257]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908260]  [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0
      [11009.908264]  [<ffffffff812e9846>] ? __module_address+0xb6/0x360
      [11009.908268]  [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0
      [11009.908271]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908275]  [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290
      [11009.908278]  [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300
      [11009.908282]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908285]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908289]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908292]  [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10
      [11009.908296]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908299]  [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400
      [11009.908302]  [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300
      [11009.908306]  [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20
      [11009.908309]  [<ffffffff8159e708>] ? put_object+0x48/0x70
      [11009.908314]  [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908317]  [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908320]  [<ffffffffa0150000>] ? 0xffffffffa0150000
      [11009.908324]  [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908327]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
      [11009.908330]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
      [11009.908333]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908337]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908340]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908343]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908346]  [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0
      [11009.908350]  [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad
      [11009.908353]  [<ffffffff812f2626>] load_module+0x6666/0x9ba0
      [11009.908356]  [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50
      [11009.908361]  [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
      [11009.908366]  [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20
      [11009.908369]  [<ffffffff815bc940>] ? open_exec+0x50/0x50
      [11009.908374]  [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0
      [11009.908377]  [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130
      [11009.908379]  [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0
      [11009.908383]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
      [11009.908394]  [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908396] Memory state around the buggy address:
      [11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
      [11009.908405]                                            ^
      [11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908411] ==================================================================
      
      In order to avoid it, let's set the cached value of the firmware
      name to NULL after freeing it. While here, return an error if
      the memory allocation fails.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e21b00fe
    • Parthasarathy Bhuvaragan's avatar
      tipc: fix random link resets while adding a second bearer · c8580e3d
      Parthasarathy Bhuvaragan authored
      [ Upstream commit d2f394dc ]
      
      In a dual bearer configuration, if the second tipc link becomes
      active while the first link still has pending nametable "bulk"
      updates, it randomly leads to reset of the second link.
      
      When a link is established, the function named_distribute(),
      fills the skb based on node mtu (allows room for TUNNEL_PROTOCOL)
      with NAME_DISTRIBUTOR message for each PUBLICATION.
      However, the function named_distribute() allocates the buffer by
      increasing the node mtu by INT_H_SIZE (to insert NAME_DISTRIBUTOR).
      This consumes the space allocated for TUNNEL_PROTOCOL.
      
      When establishing the second link, the link shall tunnel all the
      messages in the first link queue including the "bulk" update.
      As size of the NAME_DISTRIBUTOR messages while tunnelling, exceeds
      the link mtu the transmission fails (-EMSGSIZE).
      
      Thus, the synch point based on the message count of the tunnel
      packets is never reached leading to link timeout.
      
      In this commit, we adjust the size of name distributor message so that
      they can be tunnelled.
      Reviewed-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarParthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c8580e3d
    • Arnd Bergmann's avatar
      gfs2: avoid uninitialized variable warning · 5eb668f8
      Arnd Bergmann authored
      [ Upstream commit 67893f12 ]
      
      We get a bogus warning about a potential uninitialized variable
      use in gfs2, because the compiler does not figure out that we
      never use the leaf number if get_leaf_nr() returns an error:
      
      fs/gfs2/dir.c: In function 'get_first_leaf':
      fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      fs/gfs2/dir.c: In function 'dir_split_leaf':
      fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
      sufficient to let gcc understand that this is exactly the same
      condition as in IS_ERR() so it can optimize the code path enough
      to understand it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5eb668f8
    • Arnd Bergmann's avatar
      hostap: avoid uninitialized variable use in hfa384x_get_rid · 6013c31f
      Arnd Bergmann authored
      [ Upstream commit 48dc5fb3 ]
      
      The driver reads a value from hfa384x_from_bap(), which may fail,
      and then assigns the value to a local variable. gcc detects that
      in in the failure case, the 'rlen' variable now contains
      uninitialized data:
      
      In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
      drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
      drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
        if (le16_to_cpu(rec.len) == 0) {
      
      This restructures the function as suggested by Russell King, to
      make it more readable and get more reliable error handling, by
      handling each failure mode using a goto.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6013c31f
    • Arnd Bergmann's avatar
      tty: nozomi: avoid a harmless gcc warning · 56c3cd09
      Arnd Bergmann authored
      [ Upstream commit a4f642a8 ]
      
      The nozomi wireless data driver has its own helper function to
      transfer data from a FIFO, doing an extra byte swap on big-endian
      architectures, presumably to bring the data back into byte-serial
      order after readw() or readl() perform their implicit byteswap.
      
      This helper function is used in the receive_data() function to
      first read the length into a 32-bit variable, which causes
      a compile-time warning:
      
      drivers/tty/nozomi.c: In function 'receive_data':
      drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem is that gcc is unsure whether the data was actually
      read or not. We know that it is at this point, so we can replace
      it with a single readl() to shut up that warning.
      
      I am leaving the byteswap in there, to preserve the existing
      behavior, even though this seems fishy: Reading the length of
      the data into a cpu-endian variable should normally not use
      a second byteswap on big-endian systems, unless the hardware
      is aware of the CPU endianess.
      
      There appears to be a lot more confusion about endianess in this
      driver, so it probably has not worked on big-endian systems in
      a long time, if ever, and I have no way to test it. It's well
      possible that this driver has not been used by anyone in a while,
      the last patch that looks like it was tested on the hardware is
      from 2008.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      56c3cd09
    • Jon Paul Maloy's avatar
      tipc: re-enable compensation for socket receive buffer double counting · 39a978c3
      Jon Paul Maloy authored
      [ Upstream commit 7c8bcfb1 ]
      
      In the refactoring commit d570d864 ("tipc: enqueue arrived buffers
      in socket in separate function") we did by accident replace the test
      
      if (sk->sk_backlog.len == 0)
           atomic_set(&tsk->dupl_rcvcnt, 0);
      
      with
      
      if (sk->sk_backlog.len)
           atomic_set(&tsk->dupl_rcvcnt, 0);
      
      This effectively disables the compensation we have for the double
      receive buffer accounting that occurs temporarily when buffers are
      moved from the backlog to the socket receive queue. Until now, this
      has gone unnoticed because of the large receive buffer limits we are
      applying, but becomes indispensable when we reduce this buffer limit
      later in this series.
      
      We now fix this by inverting the mentioned condition.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      39a978c3
    • Dan Williams's avatar
      block: fix del_gendisk() vs blkdev_ioctl crash · 0c28e96f
      Dan Williams authored
      [ Upstream commit ac34f15e ]
      
      When tearing down a block device early in its lifetime, userspace may
      still be performing discovery actions like blkdev_ioctl() to re-read
      partitions.
      
      The nvdimm_revalidate_disk() implementation depends on
      disk->driverfs_dev to be valid at entry.  However, it is set to NULL in
      del_gendisk() and fatally this is happening *before* the disk device is
      deleted from userspace view.
      
      There's no reason for del_gendisk() to clear ->driverfs_dev.  That
      device is the parent of the disk.  It is guaranteed to not be freed
      until the disk, as a child, drops its ->parent reference.
      
      We could also fix this issue locally in nvdimm_revalidate_disk() by
      using disk_to_dev(disk)->parent, but lets fix it globally since
      ->driverfs_dev follows the lifetime of the parent.  Longer term we
      should probably just add a @parent parameter to add_disk(), and stop
      carrying this pointer in the gendisk.
      
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: [<ffffffffa00340a8>] nvdimm_revalidate_disk+0x18/0x90 [libnvdimm]
       CPU: 2 PID: 538 Comm: systemd-udevd Tainted: G           O    4.4.0-rc5 #2257
       [..]
       Call Trace:
        [<ffffffff8143e5c7>] rescan_partitions+0x87/0x2c0
        [<ffffffff810f37f9>] ? __lock_is_held+0x49/0x70
        [<ffffffff81438c62>] __blkdev_reread_part+0x72/0xb0
        [<ffffffff81438cc5>] blkdev_reread_part+0x25/0x40
        [<ffffffff8143982d>] blkdev_ioctl+0x4fd/0x9c0
        [<ffffffff811246c9>] ? current_kernel_time64+0x69/0xd0
        [<ffffffff812916dd>] block_ioctl+0x3d/0x50
        [<ffffffff81264c38>] do_vfs_ioctl+0x308/0x560
        [<ffffffff8115dbd1>] ? __audit_syscall_entry+0xb1/0x100
        [<ffffffff810031d6>] ? do_audit_syscall_entry+0x66/0x70
        [<ffffffff81264f09>] SyS_ioctl+0x79/0x90
        [<ffffffff81902672>] entry_SYSCALL_64_fastpath+0x12/0x76
      Reported-by: default avatarRobert Hu <robert.hu@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0c28e96f
    • Vitaly Kuznetsov's avatar
      Drivers: hv: balloon: account for gaps in hot add regions · 0c4670d5
      Vitaly Kuznetsov authored
      [ Upstream commit cb7a5724 ]
      
      I'm observing the following hot add requests from the WS2012 host:
      
      hot_add_req: start_pfn = 0x108200 count = 330752
      hot_add_req: start_pfn = 0x158e00 count = 193536
      hot_add_req: start_pfn = 0x188400 count = 239616
      
      As the host doesn't specify hot add regions we're trying to create
      128Mb-aligned region covering the first request, we create the 0x108000 -
      0x160000 region and we add 0x108000 - 0x158e00 memory. The second request
      passes the pfn_covered() check, we enlarge the region to 0x108000 -
      0x190000 and add 0x158e00 - 0x188200 memory. The problem emerges with the
      third request as it starts at 0x188400 so there is a 0x200 gap which is
      not covered. As the end of our region is 0x190000 now it again passes the
      pfn_covered() check were we just adjust the covered_end_pfn and make it
      0x188400 instead of 0x188200 which means that we'll try to online
      0x188200-0x188400 pages but these pages were never assigned to us and we
      crash.
      
      We can't react to such requests by creating new hot add regions as it may
      happen that the whole suggested range falls into the previously identified
      128Mb-aligned area so we'll end up adding nothing or create intersecting
      regions and our current logic doesn't allow that. Instead, create a list of
      such 'gaps' and check for them in the page online callback.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0c4670d5
    • Vitaly Kuznetsov's avatar
      Drivers: hv: balloon: keep track of where ha_region starts · 2cbbeec3
      Vitaly Kuznetsov authored
      [ Upstream commit 7cf3b79e ]
      
      Windows 2012 (non-R2) does not specify hot add region in hot add requests
      and the logic in hot_add_req() is trying to find a 128Mb-aligned region
      covering the request. It may also happen that host's requests are not 128Mb
      aligned and the created ha_region will start before the first specified
      PFN. We can't online these non-present pages but we don't remember the real
      start of the region.
      
      This is a regression introduced by the commit 5abbbb75 ("Drivers: hv:
      hv_balloon: don't lose memory when onlining order is not natural"). While
      the idea of keeping the 'moving window' was wrong (as there is no guarantee
      that hot add requests come ordered) we should still keep track of
      covered_start_pfn. This is not a revert, the logic is different.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2cbbeec3
    • Yazen Ghannam's avatar
      x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs · 5b9ab933
      Yazen Ghannam authored
      [ Upstream commit 29f72ce3 ]
      
      MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
      However, MCA bank 3 is defined on Fam17h systems and can be accessed
      using legacy MSRs. Without a name we get a stack trace on Fam17h systems
      when trying to register sysfs files for bank 3 on kernels that don't
      recognize Scalable MCA.
      
      Call MCA bank 3 "decode_unit" since this is what it represents on
      Fam17h. This will allow kernels without SMCA support to see this bank on
      Fam17h+ and prevent the stack trace. This will not affect older systems
      since this bank is reserved on them, i.e. it'll be ignored.
      
      Tested on AMD Fam15h and Fam17h systems.
      
        WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
        kobject: (ffff88085bb256c0): attempted to be registered with empty name!
        ...
        Call Trace:
         kobject_add_internal
         kobject_add
         kobject_create_and_add
         threshold_create_device
         threshold_init_device
      Signed-off-by: default avatarYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-Yazen.Ghannam@amd.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5b9ab933
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg() · 749cab85
      K. Y. Srinivasan authored
      [ Upstream commit 8de0d7e9 ]
      
      The current delay between retries is unnecessarily high and is negatively
      affecting the time it takes to boot the system.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      749cab85
    • Vitaly Kuznetsov's avatar
      Drivers: hv: don't leak memory in vmbus_establish_gpadl() · 38f9c4b9
      Vitaly Kuznetsov authored
      [ Upstream commit 7cc80c98 ]
      
      In some cases create_gpadl_header() allocates submessages but we never
      free them.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      38f9c4b9
    • Mantas M's avatar
      net: ipv6: check route protocol when deleting routes · 9f4a8ebb
      Mantas M authored
      [ Upstream commit c2ed1880 ]
      
      The protocol field is checked when deleting IPv4 routes, but ignored for
      IPv6, which causes problems with routing daemons accidentally deleting
      externally set routes (observed by multiple bird6 users).
      
      This can be verified using `ip -6 route del <prefix> proto something`.
      Signed-off-by: default avatarMantas Mikulėnas <grawity@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9f4a8ebb
    • Richard Genoud's avatar
      tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done · 5ce729a8
      Richard Genoud authored
      [ Upstream commit b389f173 ]
      
      When using RS485 in half duplex, RX should be enabled when TX is
      finished, and stopped when TX starts.
      
      Before commit 0058f087 ("tty/serial: atmel: fix RS485 half
      duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
      was used. So, collisions could happened.
      
      But disabling RX in atmel_start_tx() uncovered another bug:
      RX was enabled again in the wrong place (in atmel_tx_dma) instead of
      being enabled when TX is finished (in atmel_complete_tx_dma), so the
      transmission simply stopped.
      
      This bug was not triggered before commit 0058f087
      ("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
      never disabled before.
      
      Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarGil Weber <webergil@gmail.com>
      Fixes: 0058f087Tested-by: default avatarGil Weber <webergil@gmail.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5ce729a8
    • Ben Hutchings's avatar
      catc: Use heap buffer for memory size test · 9d86a569
      Ben Hutchings authored
      [ Upstream commit 2d6a0e9d ]
      
      Allocating USB buffers on the stack is not portable, and no longer
      works on x86_64 (with VMAP_STACK enabled as per default).
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9d86a569
    • Ben Hutchings's avatar
      4d7726af
    • Ben Hutchings's avatar
      rtl8150: Use heap buffers for all register access · 61bd90b3
      Ben Hutchings authored
      [ Upstream commit 7926aff5 ]
      
      Allocating USB buffers on the stack is not portable, and no longer
      works on x86_64 (with VMAP_STACK enabled as per default).
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      61bd90b3
    • Ben Hutchings's avatar
      pegasus: Use heap buffers for all register access · 7b69bee7
      Ben Hutchings authored
      [ Upstream commit 5593523f ]
      
      Allocating USB buffers on the stack is not portable, and no longer
      works on x86_64 (with VMAP_STACK enabled as per default).
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      References: https://bugs.debian.org/852556Reported-by: default avatarLisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
      Tested-by: default avatarLisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b69bee7
    • Omar Sandoval's avatar
      virtio-console: avoid DMA from stack · 0dd8a470
      Omar Sandoval authored
      [ Upstream commit c4baad50 ]
      
      put_chars() stuffs the buffer it gets into an sg, but that buffer may be
      on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
      manifested as printks getting turned into NUL bytes).
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0dd8a470
    • Kees Cook's avatar
      mm: Tighten x86 /dev/mem with zeroing reads · eb618d2e
      Kees Cook authored
      [ Upstream commit a4866aa8 ]
      
      Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
      disallowed. However, on x86, the first 1MB was always allowed for BIOS
      and similar things, regardless of it actually being System RAM. It was
      possible for heap to end up getting allocated in low 1MB RAM, and then
      read by things like x86info or dd, which would trip hardened usercopy:
      
      usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
      
      This changes the x86 exception for the low 1MB by reading back zeros for
      System RAM areas instead of blindly allowing them. More work is needed to
      extend this to mmap, but currently mmap doesn't go through usercopy, so
      hardened usercopy won't Oops the kernel.
      Reported-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Tested-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      eb618d2e
    • Thierry Reding's avatar
      rtc: tegra: Implement clock handling · 187887b3
      Thierry Reding authored
      [ Upstream commit 5fa40869 ]
      
      Accessing the registers of the RTC block on Tegra requires the module
      clock to be enabled. This only works because the RTC module clock will
      be enabled by default during early boot. However, because the clock is
      unused, the CCF will disable it at late_init time. This causes the RTC
      to become unusable afterwards. This can easily be reproduced by trying
      to use the RTC:
      
      	$ hwclock --rtc /dev/rtc1
      
      This will hang the system. I ran into this by following up on a report
      by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
      turns out that the rtc-tegra driver's ->shutdown() implementation will
      hang the CPU, because of the disabled clock, before the system can be
      rebooted.
      
      What confused me for a while is that the same driver is used on prior
      Tegra generations where the hang can not be observed. However, as Peter
      De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
      clock is enabled by the tegra20_timer.c clocksource driver, which uses
      the RTC to provide a persistent clock. This code is never enabled on
      64-bit Tegra because the persistent clock infrastructure does not exist
      on 64-bit ARM.
      
      The proper fix for this is to add proper clock handling to the RTC
      driver in order to ensure that the clock is enabled when the driver
      requires it. All device trees contain the clock already, therefore
      no additional changes are required.
      Reported-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Acked-By Peter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      187887b3
    • Lee, Chun-Yi's avatar
      platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event · ea215d79
      Lee, Chun-Yi authored
      [ Upstream commit 98d610c3 ]
      
      The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
      So, this patch changes the codes to setup accelerometer input device
      when detected ACERWMID_EVENT_GUID. It avoids that the accel input
      device created on every Acer machines.
      
      In addition, patch adds a clearly parsing logic of accelerometer hid
      to acer_wmi_get_handle_cb callback function. It is positive matching
      the "SENR" name with "BST0001" device to avoid non-supported hardware.
      Reported-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: Darren Hart <dvhart@infradead.org>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      [andy: slightly massage commit message]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ea215d79
    • Arnd Bergmann's avatar
      [media] dvb-usb-v2: avoid use-after-free · 4473dc37
      Arnd Bergmann authored
      [ Upstream commit 00514537 ]
      
      I ran into a stack frame size warning because of the on-stack copy of
      the USB device structure:
      
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect':
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      Copying a device structure like this is wrong for a number of other reasons
      too aside from the possible stack overflow. One of them is that the
      dev_info() call will print the name of the device later, but AFAICT
      we have only copied a pointer to the name earlier and the actual name
      has been freed by the time it gets printed.
      
      This removes the on-stack copy of the device and instead copies the
      device name using kstrdup(). I'm ignoring the possible failure here
      as both printk() and kfree() are able to deal with NULL pointers.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4473dc37
    • Paolo Bonzini's avatar
      kvm: fix page struct leak in handle_vmon · 68e9c254
      Paolo Bonzini authored
      [ Upstream commit 06ce521a ]
      
      handle_vmon gets a reference on VMXON region page,
      but does not release it. Release the reference.
      
      Found by syzkaller; based on a patch by Dmitry.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      68e9c254
    • Max Bires's avatar
      char: lack of bool string made CONFIG_DEVPORT always on · f800bced
      Max Bires authored
      [ Upstream commit f2cfa58b ]
      
      Without a bool string present, using "# CONFIG_DEVPORT is not set" in
      defconfig files would not actually unset devport. This esnured that
      /dev/port was always on, but there are reasons a user may wish to
      disable it (smaller kernel, attack surface reduction) if it's not being
      used. Adding a message here in order to make this user visible.
      Signed-off-by: default avatarMax Bires <jbires@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f800bced
    • Geert Uytterhoeven's avatar
      char: Drop bogus dependency of DEVPORT on !M68K · d1cdf638
      Geert Uytterhoeven authored
      [ Upstream commit 309124e2 ]
      
      According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
      update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
      defined.
      
      However, commit 153dcc54 ("[PATCH] mem driver: fix conditional
      on isa i/o support") accidentally changed an "||" into an "&&",
      disabling it completely on m68k. This logic was retained when
      introducing the DEVPORT symbol in commit 4f911d64 ("Make
      /dev/port conditional on config symbol").
      
      Drop the bogus dependency on !M68K to fix this.
      
      Fixes: 153dcc54 ("[PATCH] mem driver: fix conditional on isa i/o support")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarAl Stone <ahs3@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d1cdf638
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions · 6d1174d8
      Jack Morgenstein authored
      [ Upstream commit 7c3945bc ]
      
      Save the qp context flags byte containing the flag disabling vlan stripping
      in the RESET to INIT qp transition, rather than in the INIT to RTR
      transition. Per the firmware spec, the flags in this byte are active
      in the RESET to INIT transition.
      
      As a result of saving the flags in the incorrect qp transition, when
      switching dynamically from VGT to VST and back to VGT, the vlan
      remained stripped (as is required for VST) and did not return to
      not-stripped (as is required for VGT).
      
      Fixes: f0f829bf ("net/mlx4_core: Add immediate activate for VGT->VST->VGT")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6d1174d8
    • Eugenia Emantayev's avatar
      net/mlx4_en: Fix bad WQE issue · 8a8878b1
      Eugenia Emantayev authored
      [ Upstream commit 6496bbf0 ]
      
      Single send WQE in RX buffer should be stamped with software
      ownership in order to prevent the flow of QP in error in FW
      once UPDATE_QP is called.
      
      Fixes: 9f519f68 ('mlx4_en: Not using Shared Receive Queues')
      Signed-off-by: default avatarEugenia Emantayev <eugenia@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8a8878b1
    • Guenter Roeck's avatar
      usb: hub: Wait for connection to be reestablished after port reset · 037948b4
      Guenter Roeck authored
      [ Upstream commit 22547c4c ]
      
      On a system with a defective USB device connected to an USB hub,
      an endless sequence of port connect events was observed. The sequence
      of events as observed is as follows:
      
      - Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
      - Event handler debounces port and resets it by calling hub_port_reset().
      - hub_port_reset() calls hub_port_wait_reset() to wait for the reset
        to complete.
      - The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
        set in the port status register.
      - hub_port_wait_reset() returns -ENOTCONN.
      - Port initialization sequence is aborted.
      - A few milliseconds later, the port again reports a connected event,
        and the sequence repeats.
      
      This continues either forever or, randomly, stops if the connection
      is already re-established when the port status is read. It results in
      a high rate of udev events. This in turn destabilizes userspace since
      the above sequence holds the device mutex pretty much continuously
      and prevents userspace from actually reading the device status.
      
      To prevent the problem from happening, let's wait for the connection
      to be re-established after a port reset. If the device was actually
      disconnected, the code will still return an error, but it will do so
      only after the long reset timeout.
      
      Cc: Douglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      037948b4
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for priv area size · dd07486c
      Andrey Konovalov authored
      [ Upstream commit 2b6867c2 ]
      
      Subtracting tp_sizeof_priv from tp_block_size and casting to int
      to check whether one is less then the other doesn't always work
      (both of them are unsigned ints).
      
      Compare them as is instead.
      
      Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as
      it can overflow inside BLK_PLUS_PRIV otherwise.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      dd07486c
    • Matt Redfearn's avatar
      MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK · c9d0eb33
      Matt Redfearn authored
      [ Upstream commit 3cc3434f ]
      
      Since do_IRQ is now invoked on a separate IRQ stack, we select
      HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirq's may be invoked directly
      from irq_exit(), rather than requiring do_softirq_own_stack.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14744/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c9d0eb33
    • Matt Redfearn's avatar
      MIPS: Only change $28 to thread_info if coming from user mode · cd7de316
      Matt Redfearn authored
      [ Upstream commit 510d8636 ]
      
      The SAVE_SOME macro is used to save the execution context on all
      exceptions.
      If an exception occurs while executing user code, the stack is switched
      to the kernel's stack for the current task, and register $28 is switched
      to point to the current_thread_info, which is at the bottom of the stack
      region.
      If the exception occurs while executing kernel code, the stack is left,
      and this change ensures that register $28 is not updated. This is the
      correct behaviour when the kernel can be executing on the separate irq
      stack, because the thread_info will not be at the base of it.
      
      With this change, register $28 is only switched to it's kernel
      conventional usage of the currrent thread info pointer at the point at
      which execution enters kernel space. Doing it on every exception was
      redundant, but OK without an IRQ stack, but will be erroneous once that
      is introduced.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14742/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cd7de316
    • Rafał Miłecki's avatar
      mtd: bcm47xxpart: fix parsing first block after aligned TRX · aa7ae7fe
      Rafał Miłecki authored
      [ Upstream commit bd5d2131 ]
      
      After parsing TRX we should skip to the first block placed behind it.
      Our code was working only with TRX with length not aligned to the
      blocksize. In other cases (length aligned) it was missing the block
      places right after TRX.
      
      This fixes calculation and simplifies the comment.
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      aa7ae7fe
    • Janusz Dziedzic's avatar
      usb: dwc3: gadget: delay unmap of bounced requests · 1669925a
      Janusz Dziedzic authored
      [ Upstream commit de288e36 ]
      
      In the case of bounced ep0 requests, we must delay DMA operation until
      after ->complete() otherwise we might overwrite contents of req->buf.
      
      This caused problems with RNDIS gadget.
      Signed-off-by: default avatarJanusz Dziedzic <januszx.dziedzic@intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1669925a
    • Chris Salls's avatar
      mm/mempolicy.c: fix error handling in set_mempolicy and mbind. · aa612d59
      Chris Salls authored
      [ Upstream commit cf01fb99 ]
      
      In the case that compat_get_bitmap fails we do not want to copy the
      bitmap to the user as it will contain uninitialized stack data and leak
      sensitive data.
      Signed-off-by: default avatarChris Salls <salls@cs.ucsb.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      aa612d59
  2. 08 Jun, 2017 4 commits
    • Yisheng Xie's avatar
      mlock: fix mlock count can not decrease in race condition · 00fc586e
      Yisheng Xie authored
      [ Upstream commit 70feee0e ]
      
      Kefeng reported that when running the follow test, the mlock count in
      meminfo will increase permanently:
      
       [1] testcase
       linux:~ # cat test_mlockal
       grep Mlocked /proc/meminfo
        for j in `seq 0 10`
        do
       	for i in `seq 4 15`
       	do
       		./p_mlockall >> log &
       	done
       	sleep 0.2
       done
       # wait some time to let mlock counter decrease and 5s may not enough
       sleep 5
       grep Mlocked /proc/meminfo
      
       linux:~ # cat p_mlockall.c
       #include <sys/mman.h>
       #include <stdlib.h>
       #include <stdio.h>
      
       #define SPACE_LEN	4096
      
       int main(int argc, char ** argv)
       {
      	 	int ret;
      	 	void *adr = malloc(SPACE_LEN);
      	 	if (!adr)
      	 		return -1;
      
      	 	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
      	 	printf("mlcokall ret = %d\n", ret);
      
      	 	ret = munlockall();
      	 	printf("munlcokall ret = %d\n", ret);
      
      	 	free(adr);
      	 	return 0;
      	 }
      
      In __munlock_pagevec() we should decrement NR_MLOCK for each page where
      we clear the PageMlocked flag.  Commit 1ebb7cc6 ("mm: munlock: batch
      NR_MLOCK zone state updates") has introduced a bug where we don't
      decrement NR_MLOCK for pages where we clear the flag, but fail to
      isolate them from the lru list (e.g.  when the pages are on some other
      cpu's percpu pagevec).  Since PageMlocked stays cleared, the NR_MLOCK
      accounting gets permanently disrupted by this.
      
      Fix it by counting the number of page whose PageMlock flag is cleared.
      
      Fixes: 1ebb7cc6 (" mm: munlock: batch NR_MLOCK zone state updates")
      Link: http://lkml.kernel.org/r/1495678405-54569-1-git-send-email-xieyisheng1@huawei.comSigned-off-by: default avatarYisheng Xie <xieyisheng1@huawei.com>
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Joern Engel <joern@logfs.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: zhongjiang <zhongjiang@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      00fc586e
    • Naoya Horiguchi's avatar
      mm/memory-failure: introduce get_hwpoison_page() for consistent refcount handling · 00136071
      Naoya Horiguchi authored
      [ Upstream commit ead07f6a ]
      
      memory_failure() can run in 2 different mode (specified by
      MF_COUNT_INCREASED) in page refcount perspective.  When
      MF_COUNT_INCREASED is set, memory_failure() assumes that the caller
      takes a refcount of the target page.  And if cleared, memory_failure()
      takes it in it's own.
      
      In current code, however, refcounting is done differently in each caller.
      For example, madvise_hwpoison() uses get_user_pages_fast() and
      hwpoison_inject() uses get_page_unless_zero().  So this inconsistent
      refcounting causes refcount failure especially for thp tail pages.
      Typical user visible effects are like memory leak or
      VM_BUG_ON_PAGE(!page_count(page)) in isolate_lru_page().
      
      To fix this refcounting issue, this patch introduces get_hwpoison_page()
      to handle thp tail pages in the same manner for each caller of hwpoison
      code.
      
      memory_failure() might fail to split thp and in such case it returns
      without completing page isolation.  This is not good because PageHWPoison
      on the thp is still set and there's no easy way to unpoison such thps.  So
      this patch try to roll back any action to the thp in "non anonymous thp"
      case and "thp split failed" case, expecting an MCE(SRAR) generated by
      later access afterward will properly free such thps.
      
      [akpm@linux-foundation.org: fix CONFIG_HWPOISON_INJECT=m]
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      00136071
    • Naoya Horiguchi's avatar
      mm/memory-failure: split thp earlier in memory error handling · da7cbd0c
      Naoya Horiguchi authored
      [ Upstream commit 415c64c1 ]
      
      memory_failure() doesn't handle thp itself at this time and need to split
      it before doing isolation.  Currently thp is split in the middle of
      hwpoison_user_mappings(), but there're corner cases where memory_failure()
      wrongly tries to handle thp without splitting.
      
      1) "non anonymous" thp, which is not a normal operating mode of thp,
         but a memory error could hit a thp before anon_vma is initialized.  In
         such case, split_huge_page() fails and me_huge_page() (intended for
         hugetlb) is called for thp, which triggers BUG_ON in page_hstate().
      
      2) !PageLRU case, where hwpoison_user_mappings() returns with
         SWAP_SUCCESS and the result is the same as case 1.
      
      memory_failure() can't avoid splitting, so let's split it more earlier,
      which also reduces code which are prepared for both of normal page and
      thp.
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      da7cbd0c
    • Thomas Gleixner's avatar
      slub/memcg: cure the brainless abuse of sysfs attributes · aeb3435b
      Thomas Gleixner authored
      [ Upstream commit 478fe303 ]
      
      memcg_propagate_slab_attrs() abuses the sysfs attribute file functions
      to propagate settings from the root kmem_cache to a newly created
      kmem_cache.  It does that with:
      
           attr->show(root, buf);
           attr->store(new, buf, strlen(bug);
      
      Aside of being a lazy and absurd hackery this is broken because it does
      not check the return value of the show() function.
      
      Some of the show() functions return 0 w/o touching the buffer.  That
      means in such a case the store function is called with the stale content
      of the previous show().  That causes nonsense like invoking
      kmem_cache_shrink() on a newly created kmem_cache.  In the worst case it
      would cause handing in an uninitialized buffer.
      
      This should be rewritten proper by adding a propagate() callback to
      those slub_attributes which must be propagated and avoid that insane
      conversion to and from ASCII, but that's too large for a hot fix.
      
      Check at least the return value of the show() function, so calling
      store() with stale content is prevented.
      
      Steven said:
       "It can cause a deadlock with get_online_cpus() that has been uncovered
        by recent cpu hotplug and lockdep changes that Thomas and Peter have
        been doing.
      
           Possible unsafe locking scenario:
      
                 CPU0                    CPU1
                 ----                    ----
            lock(cpu_hotplug.lock);
                                         lock(slab_mutex);
                                         lock(cpu_hotplug.lock);
            lock(slab_mutex);
      
           *** DEADLOCK ***"
      
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1705201244540.2255@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      aeb3435b