1. 20 Dec, 2017 34 commits
    • monty_pavel@sina.com's avatar
      dm: fix various targets to dm_register_target after module __init resources created · fbce429b
      monty_pavel@sina.com authored
      commit 7e6358d2
      
       upstream.
      
      A NULL pointer is seen if two concurrent "vgchange -ay -K <vg name>"
      processes race to load the dm-thin-pool module:
      
       PID: 25992 TASK: ffff883cd7d23500 CPU: 4 COMMAND: "vgchange"
        #0 [ffff883cd743d600] machine_kexec at ffffffff81038fa9
        0000001 [ffff883cd743d660] crash_kexec at ffffffff810c5992
        0000002 [ffff883cd743d730] oops_end at ffffffff81515c90
        0000003 [ffff883cd743d760] no_context at ffffffff81049f1b
        0000004 [ffff883cd743d7b0] __bad_area_nosemaphore at ffffffff8104a1a5
        0000005 [ffff883cd743d800] bad_area at ffffffff8104a2ce
        0000006 [ffff883cd743d830] __do_page_fault at ffffffff8104aa6f
        0000007 [ffff883cd743d950] do_page_fault at ffffffff81517bae
        0000008 [ffff883cd743d980] page_fault at ffffffff81514f95
           [exception RIP: kmem_cache_alloc+108]
           RIP: ffffffff8116ef3c RSP: ffff883cd743da38 RFLAGS: 00010046
           RAX: 0000000000000004 RBX: ffffffff81121b90 RCX: ffff881bf1e78cc0
           RDX: 0000000000000000 RSI: 00000000000000d0 RDI: 0000000000000000
           RBP: ffff883cd743da68 R8: ffff881bf1a4eb00 R9: 0000000080042000
           R10: 0000000000002000 R11: 0000000000000000 R12: 00000000000000d0
           R13: 0000000000000000 R14: 00000000000000d0 R15: 0000000000000246
           ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
        0000009 [ffff883cd743da70] mempool_alloc_slab at ffffffff81121ba5
       0000010 [ffff883cd743da80] mempool_create_node at ffffffff81122083
       0000011 [ffff883cd743dad0] mempool_create at ffffffff811220f4
       0000012 [ffff883cd743dae0] pool_ctr at ffffffffa08de049 [dm_thin_pool]
       0000013 [ffff883cd743dbd0] dm_table_add_target at ffffffffa0005f2f [dm_mod]
       0000014 [ffff883cd743dc30] table_load at ffffffffa0008ba9 [dm_mod]
       0000015 [ffff883cd743dc90] ctl_ioctl at ffffffffa0009dc4 [dm_mod]
      
      The race results in a NULL pointer because:
      
      Process A (vgchange -ay -K):
       	a. send DM_LIST_VERSIONS_CMD ioctl;
       	b. pool_target not registered;
       	c. modprobe dm_thin_pool and wait until end.
      
      Process B (vgchange -ay -K):
       	a. send DM_LIST_VERSIONS_CMD ioctl;
       	b. pool_target registered;
       	c. table_load->dm_table_add_target->pool_ctr;
       	d. _new_mapping_cache is NULL and panic.
      Note:
       	1. process A and process B are two concurrent processes.
       	2. pool_target can be detected by process B but
       	_new_mapping_cache initialization has not ended.
      
      To fix dm-thin-pool, and other targets (cache, multipath, and snapshot)
      with the same problem, simply dm_register_target() after all resources
      created during module init (as labelled with __init) are finished.
      Signed-off-by: default avatarmonty <monty_pavel@sina.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbce429b
    • Steven Rostedt's avatar
      sched/rt: Do not pull from current CPU if only one CPU to pull · 282e4b25
      Steven Rostedt authored
      commit f73c52a5
      
       upstream.
      
      Daniel Wagner reported a crash on the BeagleBone Black SoC.
      
      This is a single CPU architecture, and does not have a functional
      arch_send_call_function_single_ipi() implementation which can crash
      the kernel if that is called.
      
      As it only has one CPU, it shouldn't be called, but if the kernel is
      compiled for SMP, the push/pull RT scheduling logic now calls it for
      irq_work if the one CPU is overloaded, it can use that function to call
      itself and crash the kernel.
      
      Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
      only has a single CPU. But SCHED_FEAT is a constant if sched debugging
      is turned off. Another fix can also be used, and this should also help
      with normal SMP machines. That is, do not initiate the pull code if
      there's only one RT overloaded CPU, and that CPU happens to be the
      current CPU that is scheduling in a lower priority task.
      
      Even on a system with many CPUs, if there's many RT tasks waiting to
      run on a single CPU, and that CPU schedules in another RT task of lower
      priority, it will initiate the PULL logic in case there's a higher
      priority RT task on another CPU that is waiting to run. But if there is
      no other CPU with waiting RT tasks, it will initiate the RT pull logic
      on itself (as it still has RT tasks waiting to run). This is a wasted
      effort.
      
      Not only does this help with SMP code where the current CPU is the only
      one with RT overloaded tasks, it should also solve the issue that
      Daniel encountered, because it will prevent the PULL logic from
      executing, as there's only one CPU on the system, and the check added
      here will cause it to exit the RT pull code.
      Reported-by: default avatarDaniel Wagner <wagi@monom.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-rt-users <linux-rt-users@vger.kernel.org>
      Fixes: 4bdced5c ("sched/rt: Simplify the IPI based RT balancing logic")
      Link: http://lkml.kernel.org/r/20171202130454.4cbbfe8d@vmware.local.home
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      282e4b25
    • Jason Yan's avatar
      scsi: libsas: fix length error in sas_smp_handler() · c2f79ce3
      Jason Yan authored
      commit 621f6401 upstream.
      
      The return value of smp_execute_task_sg() is the untransferred residual,
      but bsg_job_done() requires the length of payload received. This makes
      SMP passthrough commands from userland by sg ioctl to libsas get a wrong
      response. The userland tools such as smp_utils failed because of these
      wrong responses:
      
      ~#smp_discover /dev/bsg/expander-2\:13
      response too short, len=0
      ~#smp_discover /dev/bsg/expander-2\:134
      response too short, len=0
      
      Fix this by passing the actual received length to bsg_job_done(). And if
      smp_execute_task_sg() returns 0, this means received length is exactly
      the buffer length.
      
      [mkp: typo]
      
      Fixes: 651a0136
      
       ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Reported-by: default avatarchenqilin <chenqilin2@huawei.com>
      Tested-by: default avatarchenqilin <chenqilin2@huawei.com>
      CC: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2f79ce3
    • Bart Van Assche's avatar
      scsi: core: Fix a scsi_show_rq() NULL pointer dereference · 39c4330c
      Bart Van Assche authored
      commit 14e3062f upstream.
      
      Avoid that scsi_show_rq() triggers a NULL pointer dereference if called
      after sd_uninit_command(). Swap the NULL pointer assignment and the
      mempool_free() call in sd_uninit_command() to make it less likely that
      scsi_show_rq() triggers a use-after-free. Note: even with these changes
      scsi_show_rq() can trigger a use-after-free but that's a lesser evil
      than e.g. suppressing debug information for T10 PI Type 2 commands
      completely. This patch fixes the following oops:
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: scsi_format_opcode_name+0x1a/0x1c0
      CPU: 1 PID: 1881 Comm: cat Not tainted 4.14.0-rc2.blk_mq_io_hang+ #516
      Call Trace:
       __scsi_format_command+0x27/0xc0
       scsi_show_rq+0x5c/0xc0
       __blk_mq_debugfs_rq_show+0x116/0x130
       blk_mq_debugfs_rq_show+0xe/0x10
       seq_read+0xfe/0x3b0
       full_proxy_read+0x54/0x90
       __vfs_read+0x37/0x160
       vfs_read+0x96/0x130
       SyS_read+0x55/0xc0
       entry_SYSCALL_64_fastpath+0x1a/0xa5
      
      [mkp: added Type 2]
      
      Fixes: 0eebd005
      
       ("scsi: Implement blk_mq_ops.show_rq()")
      Reported-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Ming Lei <ming.lei@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39c4330c
    • Mark Rutland's avatar
      arm64: fix CONFIG_DEBUG_WX address reporting · 9854611c
      Mark Rutland authored
      commit 1d08a044 upstream.
      
      In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather
      than VA_START) for the init_mm. This means that any reported W&X
      addresses are offset by VA_START, which is clearly wrong and can make
      them appear like userspace addresses.
      
      Fix this by telling the ptdump code that we're walking init_mm starting
      at VA_START. We don't need to update the addr_markers, since these are
      still valid bounds regardless.
      
      Fixes: 1404d6f1
      
       ("arm64: dump: Add checking for writable and exectuable pages")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Laura Abbott <labbott@redhat.com>
      Reported-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9854611c
    • Steve Capper's avatar
      arm64: Initialise high_memory global variable earlier · cdcfd13a
      Steve Capper authored
      commit f24e5834 upstream.
      
      The high_memory global variable is used by
      cma_declare_contiguous(.) before it is defined.
      
      We don't notice this as we compute __pa(high_memory - 1), and it looks
      like we're processing a VA from the direct linear map.
      
      This problem becomes apparent when we flip the kernel virtual address
      space and the linear map is moved to the bottom of the kernel VA space.
      
      This patch moves the initialisation of high_memory before it used.
      
      Fixes: f7426b98
      
       ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cdcfd13a
    • Steve Capper's avatar
      arm64: mm: Fix pte_mkclean, pte_mkdirty semantics · db9d4784
      Steve Capper authored
      commit 8781bcbc upstream.
      
      On systems with hardware dirty bit management, the ltp madvise09 unit
      test fails due to dirty bit information being lost and pages being
      incorrectly freed.
      
      This was bisected to:
      	arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()
      
      Reverting this commit leads to a separate problem, that the unit test
      retains pages that should have been dropped due to the function
      madvise_free_pte_range(.) not cleaning pte's properly.
      
      Currently pte_mkclean only clears the software dirty bit, thus the
      following code sequence can appear:
      
      	pte = pte_mkclean(pte);
      	if (pte_dirty(pte))
      		// this condition can return true with HW DBM!
      
      This patch also adjusts pte_mkclean to set PTE_RDONLY thus effectively
      clearing both the SW and HW dirty information.
      
      In order for this to function on systems without HW DBM, we need to
      also adjust pte_mkdirty to remove the read only bit from writable pte's
      to avoid infinite fault loops.
      
      Fixes: 64c26841
      
       ("arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()")
      Reported-by: default avatarBhupinder Thakur <bhupinder.thakur@linaro.org>
      Tested-by: default avatarBhupinder Thakur <bhupinder.thakur@linaro.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db9d4784
    • Scott Mayhew's avatar
      nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests · 268b2cc3
      Scott Mayhew authored
      commit dc4fd9ab
      
       upstream.
      
      If there were no commit requests, then nfs_commit_inode() should not
      wait on the commit or mark the inode dirty, otherwise the following
      BUG_ON can be triggered:
      
      [ 1917.130762] kernel BUG at fs/inode.c:578!
      [ 1917.130766] Oops: Exception in kernel mode, sig: 5 [#1]
      [ 1917.130768] SMP NR_CPUS=2048 NUMA pSeries
      [ 1917.130772] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi blocklayoutdriver rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc sg nx_crypto pseries_rng ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
      [ 1917.130805] CPU: 2 PID: 14923 Comm: umount.nfs4 Tainted: G               ------------ T 3.10.0-768.el7.ppc64 #1
      [ 1917.130810] task: c0000005ecd88040 ti: c00000004cea0000 task.ti: c00000004cea0000
      [ 1917.130813] NIP: c000000000354178 LR: c000000000354160 CTR: c00000000012db80
      [ 1917.130816] REGS: c00000004cea3720 TRAP: 0700   Tainted: G               ------------ T  (3.10.0-768.el7.ppc64)
      [ 1917.130820] MSR: 8000000100029032 <SF,EE,ME,IR,DR,RI>  CR: 22002822  XER: 20000000
      [ 1917.130828] CFAR: c00000000011f594 SOFTE: 1
      GPR00: c000000000354160 c00000004cea39a0 c0000000014c4700 c0000000018cc750
      GPR04: 000000000000c750 80c0000000000000 0600000000000000 04eeb76bea749a03
      GPR08: 0000000000000034 c0000000018cc758 0000000000000001 d000000005e619e8
      GPR12: c00000000012db80 c000000007b31200 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 c000000000dfc3ec 0000000000000000 c0000005eefc02c0
      GPR28: d0000000079dbd50 c0000005b94a02c0 c0000005b94a0250 c0000005b94a01c8
      [ 1917.130867] NIP [c000000000354178] .evict+0x1c8/0x350
      [ 1917.130871] LR [c000000000354160] .evict+0x1b0/0x350
      [ 1917.130873] Call Trace:
      [ 1917.130876] [c00000004cea39a0] [c000000000354160] .evict+0x1b0/0x350 (unreliable)
      [ 1917.130880] [c00000004cea3a30] [c0000000003558cc] .evict_inodes+0x13c/0x270
      [ 1917.130884] [c00000004cea3af0] [c000000000327d20] .kill_anon_super+0x70/0x1e0
      [ 1917.130896] [c00000004cea3b80] [d000000005e43e30] .nfs_kill_super+0x20/0x60 [nfs]
      [ 1917.130900] [c00000004cea3c00] [c000000000328a20] .deactivate_locked_super+0xa0/0x1b0
      [ 1917.130903] [c00000004cea3c80] [c00000000035ba54] .cleanup_mnt+0xd4/0x180
      [ 1917.130907] [c00000004cea3d10] [c000000000119034] .task_work_run+0x114/0x150
      [ 1917.130912] [c00000004cea3db0] [c00000000001ba6c] .do_notify_resume+0xcc/0x100
      [ 1917.130916] [c00000004cea3e30] [c00000000000a7b0] .ret_from_except_lite+0x5c/0x60
      [ 1917.130919] Instruction dump:
      [ 1917.130921] 7fc3f378 486734b5 60000000 387f00a0 38800003 4bdcb365 60000000 e95f00a0
      [ 1917.130927] 694a0060 7d4a0074 794ad182 694a0001 <0b0a0000> 892d02a4 2f890000 40de0134
      Signed-off-by: default avatarScott Mayhew <smayhew@redhat.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      268b2cc3
    • Daniel Jurgens's avatar
      IB/core: Don't enforce PKey security on SMI MADs · 74b6274f
      Daniel Jurgens authored
      commit 0fbe8f57
      
       upstream.
      
      Per the infiniband spec an SMI MAD can have any PKey. Checking the pkey
      on SMI MADs is not necessary, and it seems that some older adapters
      using the mthca driver don't follow the convention of using the default
      PKey, resulting in false denials, or errors querying the PKey cache.
      
      SMI MAD security is still enforced, only agents allowed to manage the
      subnet are able to receive or send SMI MADs.
      Reported-by: default avatarChris Blake <chrisrblake93@gmail.com>
      Fixes: 47a2b338
      
       ("IB/core: Enforce security on management datagrams")
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74b6274f
    • Daniel Jurgens's avatar
      IB/core: Bound check alternate path port number · 4995bfa9
      Daniel Jurgens authored
      commit 4cae8ff1 upstream.
      
      The alternate port number is used as an array index in the IB
      security implementation, invalid values can result in a kernel panic.
      
      Fixes: d291f1a6
      
       ("IB/core: Enforce PKey security on QPs")
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4995bfa9
    • Mathias Nyman's avatar
      xhci: Don't add a virt_dev to the devs array before it's fully allocated · 2b3ff282
      Mathias Nyman authored
      commit 5d9b70f7
      
       upstream.
      
      Avoid null pointer dereference if some function is walking through the
      devs array accessing members of a new virt_dev that is mid allocation.
      
      Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
      members are properly allocated.
      
      issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
      
      "Quick analysis suggests that xhci_alloc_virt_device() is not mutex
      protected. If so, there is a time frame where xhci->devs[slot_id] is set
      but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b3ff282
    • Chunfeng Yun's avatar
      usb: xhci: fix TDS for MTK xHCI1.1 · 912fe791
      Chunfeng Yun authored
      commit 72b663a9
      
       upstream.
      
      For MTK's xHCI 1.0 or latter, TD size is the number of max
      packet sized packets remaining in the TD, not including
      this TRB (following spec).
      
      For MTK's xHCI 0.96 and older, TD size is the number of max
      packet sized packets remaining in the TD, including this TRB
      (not following spec).
      Signed-off-by: default avatarChunfeng Yun <chunfeng.yun@mediatek.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      912fe791
    • Yan, Zheng's avatar
      ceph: drop negative child dentries before try pruning inode's alias · eae219a2
      Yan, Zheng authored
      commit 040d7860
      
       upstream.
      
      Negative child dentry holds reference on inode's alias, it makes
      d_prune_aliases() do nothing.
      Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eae219a2
    • Christoph Fritz's avatar
      mmc: core: apply NO_CMD23 quirk to some specific cards · 318cea7d
      Christoph Fritz authored
      commit 91516a2a
      
       upstream.
      
      To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs
      to be disabled.  This has been tested on i.MX6 (sdhci-esdhc) and rk3288
      (dw_mmc-rockchip).
      
      Without this patch on i.MX6 (sdhci-esdhc):
      
       $ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync
      
          | <mmc0: starting CMD23 arg 00000400 flags 00000015>
          | mmc0: starting CMD25 arg 00a71f00 flags 000000b5
          | mmc0:     blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0
          | mmc0:     CMD12 arg 00000000 flags 0000049d
          | sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
          | mmc0: Timeout waiting for hardware interrupt.
      
      Without this patch on rk3288 (dw_mmc-rockchip):
      
          | mmc1: Card stuck in programming state! mmcblk1 card_busy_detect
          | dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway
          | mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz,
          | actual 400000HZ div = 0)
          | mmc1: card never left busy state
          | mmc1: tried to reset card, got error -110
          | blk_update_request: I/O error, dev mmcblk1, sector 139778
          | Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async
          | page write
      Signed-off-by: default avatarChristoph Fritz <chf.fritz@googlemail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      318cea7d
    • Shuah Khan's avatar
      usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer · d78a5506
      Shuah Khan authored
      commit be6123df
      
       upstream.
      
      stub_send_ret_submit() handles urb with a potential null transfer_buffer,
      when it replays a packet with potential malicious data that could contain
      a null buffer. Add a check for the condition when actual_length > 0 and
      transfer_buffer is null.
      Reported-by: default avatarSecunia Research <vuln@secunia.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d78a5506
    • Shuah Khan's avatar
      usbip: prevent vhci_hcd driver from leaking a socket pointer address · b6a2ad64
      Shuah Khan authored
      commit 2f2d0088
      
       upstream.
      
      When a client has a USB device attached over IP, the vhci_hcd driver is
      locally leaking a socket pointer address via the
      
      /sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
      output when "usbip --debug port" is run.
      
      Fix it to not leak. The socket pointer address is not used at the moment
      and it was made visible as a convenient way to find IP address from socket
      pointer address by looking up /proc/net/{tcp,tcp6}.
      
      As this opens a security hole, the fix replaces socket pointer address with
      sockfd.
      Reported-by: default avatarSecunia Research <vuln@secunia.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6a2ad64
    • Shuah Khan's avatar
      usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input · 1621db05
      Shuah Khan authored
      commit c6688ef9
      
       upstream.
      
      Harden CMD_SUBMIT path to handle malicious input that could trigger
      large memory allocations. Add checks to validate transfer_buffer_length
      and number_of_packets to protect against bad input requesting for
      unbounded memory allocations. Validate early in get_pipe() and return
      failure.
      Reported-by: default avatarSecunia Research <vuln@secunia.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1621db05
    • Shuah Khan's avatar
      usbip: fix stub_rx: get_pipe() to validate endpoint number · 7120d742
      Shuah Khan authored
      commit 635f545a
      
       upstream.
      
      get_pipe() routine doesn't validate the input endpoint number
      and uses to reference ep_in and ep_out arrays. Invalid endpoint
      number can trigger BUG(). Range check the epnum and returning
      error instead of calling BUG().
      
      Change caller stub_recv_cmd_submit() to handle the get_pipe()
      error return.
      Reported-by: default avatarSecunia Research <vuln@secunia.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7120d742
    • Amir Goldstein's avatar
      ovl: update ctx->pos on impure dir iteration · cb6ee0f3
      Amir Goldstein authored
      commit b02a16e6
      
       upstream.
      
      This fixes a regression with readdir of impure dir in overlayfs
      that is shared to VM via 9p fs.
      Reported-by: default avatarMiguel Bernal Marin <miguel.bernal.marin@linux.intel.com>
      Fixes: 4edb83bb
      
       ("ovl: constant d_ino for non-merge dirs")
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Tested-by: default avatarMiguel Bernal Marin <miguel.bernal.marin@linux.intel.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb6ee0f3
    • Vivek Goyal's avatar
      ovl: Pass ovl_get_nlink() parameters in right order · 066f40dc
      Vivek Goyal authored
      commit 08d8f8a5
      
       upstream.
      
      Right now we seem to be passing index as "lowerdentry" and origin.dentry
      as "upperdentry". IIUC, we should pass these parameters in reversed order
      and this looks like a bug.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Acked-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Fixes: caf70cb2
      
       ("ovl: cleanup orphan index entries")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      066f40dc
    • Alan Stern's avatar
      USB: core: prevent malicious bNumInterfaces overflow · 4c5ae6a3
      Alan Stern authored
      commit 48a4ff1c
      
       upstream.
      
      A malicious USB device with crafted descriptors can cause the kernel
      to access unallocated memory by setting the bNumInterfaces value too
      high in a configuration descriptor.  Although the value is adjusted
      during parsing, this adjustment is skipped in one of the error return
      paths.
      
      This patch prevents the problem by setting bNumInterfaces to 0
      initially.  The existing code already sets it to the proper value
      after parsing is complete.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c5ae6a3
    • David Kozub's avatar
      USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID · 63912948
      David Kozub authored
      commit 62354454
      
       upstream.
      
      There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
      with the following error:
      
      [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
      [sda] tag#0 Sense Key : Illegal Request [current]
      [sda] tag#0 Add. Sense: Invalid field in cdb
      
      The issue occurs both with UAS (occasionally) and mass storage
      (immediately after mounting a FS on a disk in the enclosure).
      
      Enabling US_FL_BROKEN_FUA quirk solves this issue.
      
      This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
      for both UAS and mass storage.
      Signed-off-by: default avatarDavid Kozub <zub@linux.fjfi.cvut.cz>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63912948
    • Changbin Du's avatar
      tracing: Allocate mask_str buffer dynamically · b8582c0f
      Changbin Du authored
      commit 90e406f9 upstream.
      
      The default NR_CPUS can be very large, but actual possible nr_cpu_ids
      usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
      nr_cpu_ids is 4. About 2 pages are wasted.
      
      Most machines don't have so many CPUs, so define a array with NR_CPUS
      just wastes memory. So let's allocate the buffer dynamically when need.
      
      With this change, the mutext tracing_cpumask_update_lock also can be
      removed now, which was used to protect mask_str.
      
      Link: http://lkml.kernel.org/r/1512013183-19107-1-git-send-email-changbin.du@intel.com
      
      Fixes: 36dfe925
      
       ("ftrace: make use of tracing_cpumask")
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8582c0f
    • Michal Hocko's avatar
      mm, oom_reaper: fix memory corruption · 55fe4698
      Michal Hocko authored
      commit 4837fe37 upstream.
      
      David Rientjes has reported the following memory corruption while the
      oom reaper tries to unmap the victims address space
      
        BUG: Bad page map in process oom_reaper  pte:6353826300000000 pmd:00000000
        addr:00007f50cab1d000 vm_flags:08100073 anon_vma:ffff9eea335603f0 mapping:          (null) index:7f50cab1d
        file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
        CPU: 2 PID: 1001 Comm: oom_reaper
        Call Trace:
           unmap_page_range+0x1068/0x1130
           __oom_reap_task_mm+0xd5/0x16b
           oom_reaper+0xff/0x14c
           kthread+0xc1/0xe0
      
      Tetsuo Handa has noticed that the synchronization inside exit_mmap is
      insufficient.  We only synchronize with the oom reaper if
      tsk_is_oom_victim which is not true if the final __mmput is called from
      a different context than the oom victim exit path.  This can trivially
      happen from context of any task which has grabbed mm reference (e.g.  to
      read /proc/<pid>/ file which requires mm etc.).
      
      The race would look like this
      
        oom_reaper		oom_victim		task
      						mmget_not_zero
      			do_exit
      			  mmput
        __oom_reap_task_mm				mmput
        						  __mmput
      						    exit_mmap
      						      remove_vma
          unmap_page_range
      
      Fix this issue by providing a new mm_is_oom_victim() helper which
      operates on the mm struct rather than a task.  Any context which
      operates on a remote mm struct should use this helper in place of
      tsk_is_oom_victim.  The flag is set in mark_oom_victim and never cleared
      so it is stable in the exit_mmap path.
      
      Debugged by Tetsuo Handa.
      
      Link: http://lkml.kernel.org/r/20171210095130.17110-1-mhocko@kernel.org
      Fixes: 21292580
      
       ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Andrea Argangeli <andrea@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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55fe4698
    • Thiago Rafael Becker's avatar
      kernel: make groups_sort calling a responsibility group_info allocators · c5d9b78d
      Thiago Rafael Becker authored
      commit bdcf0a42 upstream.
      
      In testing, we found that nfsd threads may call set_groups in parallel
      for the same entry cached in auth.unix.gid, racing in the call of
      groups_sort, corrupting the groups for that entry and leading to
      permission denials for the client.
      
      This patch:
       - Make groups_sort globally visible.
       - Move the call to groups_sort to the modifiers of group_info
       - Remove the call to groups_sort from set_groups
      
      Link: http://lkml.kernel.org/r/20171211151420.18655-1-thiago.becker@gmail.com
      
      Signed-off-by: default avatarThiago Rafael Becker <thiago.becker@gmail.com>
      Reviewed-by: default avatarMatthew Wilcox <mawilcox@microsoft.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Acked-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5d9b78d
    • NeilBrown's avatar
      autofs: fix careless error in recent commit · d3d2f01a
      NeilBrown authored
      commit 302ec300 upstream.
      
      Commit ecc0c469 ("autofs: don't fail mount for transient error") was
      meant to replace an 'if' with a 'switch', but instead added the 'switch'
      leaving the case in place.
      
      Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
      Fixes: ecc0c469
      
       ("autofs: don't fail mount for transient error")
      Reported-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Cc: Ian Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3d2f01a
    • Arnd Bergmann's avatar
      string.h: workaround for increased stack usage · c8def7a4
      Arnd Bergmann authored
      commit 146734b0 upstream.
      
      The hardened strlen() function causes rather large stack usage in at
      least one file in the kernel, in particular when CONFIG_KASAN is
      enabled:
      
        drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
        drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
      
      Analyzing this problem led to the discovery that gcc fails to merge the
      stack slots for the i2c_board_info[] structures after we strlcpy() into
      them, due to the 'noreturn' attribute on the source string length check.
      
      I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
      since it is relatively easy to work around, and it gets triggered
      rarely.  An earlier workaround I did added an empty inline assembly
      statement before the call to fortify_panic(), which works surprisingly
      well, but is really ugly and unintuitive.
      
      This is a new approach to the same problem, this time addressing it by
      not calling the 'extern __real_strnlen()' function for string constants
      where __builtin_strlen() is a compile-time constant and therefore known
      to be safe.
      
      We do this by checking if the last character in the string is a
      compile-time constant '\0'.  If it is, we can assume that strlen() of
      the string is also constant.
      
      As a side-effect, this should also improve the object code output for
      any other call of strlen() on a string constant.
      
      [akpm@linux-foundation.org: add comment]
      Link: http://lkml.kernel.org/r/20171205215143.3085755-1-arnd@arndb.de
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
      Link: https://patchwork.kernel.org/patch/9980413/
      Link: https://patchwork.kernel.org/patch/9974047/
      Fixes: 6974f0c4
      
       ("include/linux/string.h: add the option of fortified string.h functions")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Martin Wilck <mwilck@suse.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8def7a4
    • Ronnie Sahlberg's avatar
      6f3fc5f9
    • Eric Biggers's avatar
      crypto: af_alg - fix NULL pointer dereference in · cf1048e4
      Eric Biggers authored
      commit 887207ed upstream.
      
       af_alg_free_areq_sgls()
      
      If allocating the ->tsgl member of 'struct af_alg_async_req' failed,
      during cleanup we dereferenced the NULL ->tsgl pointer in
      af_alg_free_areq_sgls(), because ->tsgl_entries was nonzero.
      
      Fix it by only freeing the ->tsgl list if it is non-NULL.
      
      This affected both algif_skcipher and algif_aead.
      
      Fixes: e870456d ("crypto: algif_skcipher - overhaul memory management")
      Fixes: d887c52d
      
       ("crypto: algif_aead - overhaul memory management")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf1048e4
    • Eric Biggers's avatar
      crypto: salsa20 - fix blkcipher_walk API usage · c68b3152
      Eric Biggers authored
      commit ecaaab56
      
       upstream.
      
      When asked to encrypt or decrypt 0 bytes, both the generic and x86
      implementations of Salsa20 crash in blkcipher_walk_done(), either when
      doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
      because walk->buffer and walk->page have not been initialized.
      
      The bug is that Salsa20 is calling blkcipher_walk_done() even when
      nothing is in 'walk.nbytes'.  But blkcipher_walk_done() is only meant to
      be called when a nonzero number of bytes have been provided.
      
      The broken code is part of an optimization that tries to make only one
      call to salsa20_encrypt_bytes() to process inputs that are not evenly
      divisible by 64 bytes.  To fix the bug, just remove this "optimization"
      and use the blkcipher_walk API the same way all the other users do.
      
      Reproducer:
      
          #include <linux/if_alg.h>
          #include <sys/socket.h>
          #include <unistd.h>
      
          int main()
          {
                  int algfd, reqfd;
                  struct sockaddr_alg addr = {
                          .salg_type = "skcipher",
                          .salg_name = "salsa20",
                  };
                  char key[16] = { 0 };
      
                  algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
                  bind(algfd, (void *)&addr, sizeof(addr));
                  reqfd = accept(algfd, 0, 0);
                  setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
                  read(reqfd, key, sizeof(key));
          }
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Fixes: eb6f13eb
      
       ("[CRYPTO] salsa20_generic: Fix multi-page processing")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c68b3152
    • Eric Biggers's avatar
      crypto: hmac - require that the underlying hash algorithm is unkeyed · 902ae89f
      Eric Biggers authored
      commit af3ff804
      
       upstream.
      
      Because the HMAC template didn't check that its underlying hash
      algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
      through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
      being used without having been keyed, resulting in sha3_update() being
      called without sha3_init(), causing a stack buffer overflow.
      
      This is a very old bug, but it seems to have only started causing real
      problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
      because the innermost hash's state is ->import()ed from a zeroed buffer,
      and it just so happens that other hash algorithms are fine with that,
      but SHA-3 is not.  However, there could be arch or hardware-dependent
      hash algorithms also affected; I couldn't test everything.
      
      Fix the bug by introducing a function crypto_shash_alg_has_setkey()
      which tests whether a shash algorithm is keyed.  Then update the HMAC
      template to require that its underlying hash algorithm is unkeyed.
      
      Here is a reproducer:
      
          #include <linux/if_alg.h>
          #include <sys/socket.h>
      
          int main()
          {
              int algfd;
              struct sockaddr_alg addr = {
                  .salg_type = "hash",
                  .salg_name = "hmac(hmac(sha3-512-generic))",
              };
              char key[4096] = { 0 };
      
              algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
              bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
              setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
          }
      
      Here was the KASAN report from syzbot:
      
          BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341  [inline]
          BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0  crypto/sha3_generic.c:161
          Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
      
          CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
          Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  Google 01/01/2011
          Call Trace:
            __dump_stack lib/dump_stack.c:17 [inline]
            dump_stack+0x194/0x257 lib/dump_stack.c:53
            print_address_description+0x73/0x250 mm/kasan/report.c:252
            kasan_report_error mm/kasan/report.c:351 [inline]
            kasan_report+0x25b/0x340 mm/kasan/report.c:409
            check_memory_region_inline mm/kasan/kasan.c:260 [inline]
            check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
            memcpy+0x37/0x50 mm/kasan/kasan.c:303
            memcpy include/linux/string.h:341 [inline]
            sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
            crypto_shash_update+0xcb/0x220 crypto/shash.c:109
            shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
            crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
            hmac_finup+0x182/0x330 crypto/hmac.c:152
            crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
            shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
            crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
            hmac_setkey+0x36a/0x690 crypto/hmac.c:66
            crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
            shash_async_setkey+0x47/0x60 crypto/shash.c:207
            crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
            hash_setkey+0x40/0x90 crypto/algif_hash.c:446
            alg_setkey crypto/af_alg.c:221 [inline]
            alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
            SYSC_setsockopt net/socket.c:1851 [inline]
            SyS_setsockopt+0x189/0x360 net/socket.c:1830
            entry_SYSCALL_64_fastpath+0x1f/0x96
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      902ae89f
    • Eric Biggers's avatar
      crypto: rsa - fix buffer overread when stripping leading zeroes · 80dbdc5a
      Eric Biggers authored
      commit d2890c37 upstream.
      
      In rsa_get_n(), if the buffer contained all 0's and "FIPS mode" is
      enabled, we would read one byte past the end of the buffer while
      scanning the leading zeroes.  Fix it by checking 'n_sz' before '!*ptr'.
      
      This bug was reachable by adding a specially crafted key of type
      "asymmetric" (requires CONFIG_RSA and CONFIG_X509_CERTIFICATE_PARSER).
      
      KASAN report:
      
          BUG: KASAN: slab-out-of-bounds in rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
          Read of size 1 at addr ffff88003501a708 by task keyctl/196
      
          CPU: 1 PID: 196 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bb #26
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
          Call Trace:
           rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
           asn1_ber_decoder+0x82a/0x1fd0 lib/asn1_decoder.c:328
           rsa_set_pub_key+0xd3/0x320 crypto/rsa.c:278
           crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
           pkcs1pad_set_pub_key+0xae/0x200 crypto/rsa-pkcs1pad.c:117
           crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
           public_key_verify_signature+0x270/0x9d0 crypto/asymmetric_keys/public_key.c:106
           x509_check_for_self_signed+0x2ea/0x480 crypto/asymmetric_keys/x509_public_key.c:141
           x509_cert_parse+0x46a/0x620 crypto/asymmetric_keys/x509_cert_parser.c:129
           x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
           asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
           key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
           SYSC_add_key security/keys/keyctl.c:122 [inline]
           SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
           entry_SYSCALL_64_fastpath+0x1f/0x96
      
          Allocated by task 196:
           __do_kmalloc mm/slab.c:3711 [inline]
           __kmalloc_track_caller+0x118/0x2e0 mm/slab.c:3726
           kmemdup+0x17/0x40 mm/util.c:118
           kmemdup ./include/linux/string.h:414 [inline]
           x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
           x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
           asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
           key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
           SYSC_add_key security/keys/keyctl.c:122 [inline]
           SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
           entry_SYSCALL_64_fastpath+0x1f/0x96
      
      Fixes: 5a7de973
      
       ("crypto: rsa - return raw integers for the ASN.1 parser")
      Cc: Tudor Ambarus <tudor-dan.ambarus@nxp.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Reviewed-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80dbdc5a
    • Eric Biggers's avatar
      crypto: algif_aead - fix reference counting of null skcipher · 96c2dfae
      Eric Biggers authored
      commit b32a7dc8 upstream.
      
      In the AEAD interface for AF_ALG, the reference to the "null skcipher"
      held by each tfm was being dropped in the wrong place -- when each
      af_alg_ctx was freed instead of when the aead_tfm was freed.  As
      discovered by syzkaller, a specially crafted program could use this to
      cause the null skcipher to be freed while it is still in use.
      
      Fix it by dropping the reference in the right place.
      
      Fixes: 72548b09
      
       ("crypto: algif_aead - copy AAD from src to dst")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96c2dfae
    • Martin Kaiser's avatar
      mfd: fsl-imx25: Clean up irq settings during removal · 3d27b022
      Martin Kaiser authored
      commit 18f77393
      
       upstream.
      
      When fsl-imx25-tsadc is compiled as a module, loading, unloading and
      reloading the module will lead to a crash.
      
      Unable to handle kernel paging request at virtual address bf005430
      [<c004df6c>] (irq_find_matching_fwspec)
         from [<c028d5ec>] (of_irq_get+0x58/0x74)
      [<c028d594>] (of_irq_get)
         from [<c01ff970>] (platform_get_irq+0x48/0xc8)
      [<c01ff928>] (platform_get_irq)
         from [<bf00e33c>] (mx25_tsadc_probe+0x220/0x2f4 [fsl_imx25_tsadc])
      
      irq_find_matching_fwspec() loops over all registered irq domains. The
      irq domain is still registered from last time the module was loaded but
      the pointer to its operations is invalid after the module was unloaded.
      
      Add a removal function which clears the irq handler and removes the irq
      domain. With this cleanup in place, it's possible to unload and reload
      the module.
      Signed-off-by: default avatarMartin Kaiser <martin@kaiser.cx>
      Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d27b022
  2. 17 Dec, 2017 6 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.7 · 3afae843
      Greg Kroah-Hartman authored
      3afae843
    • Mauro Carvalho Chehab's avatar
      dvb_frontend: don't use-after-free the frontend struct · 7bc8eb30
      Mauro Carvalho Chehab authored
      commit b1cb7372 upstream.
      
      dvb_frontend_invoke_release() may free the frontend struct.
      So, the free logic can't update it anymore after calling it.
      
      That's OK, as __dvb_frontend_free() is called only when the
      krefs are zeroed, so nobody is using it anymore.
      
      That should fix the following KASAN error:
      
      The KASAN report looks like this (running on kernel 3e0cc09a (4.14-rc5+)):
      ==================================================================
      BUG: KASAN: use-after-free in __dvb_frontend_free+0x113/0x120
      Write of size 8 at addr ffff880067d45a00 by task kworker/0:1/24
      
      CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 #545
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
      Call Trace:
       __dump_stack lib/dump_stack.c:16
       dump_stack+0x292/0x395 lib/dump_stack.c:52
       print_address_description+0x78/0x280 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351
       kasan_report+0x23d/0x350 mm/kasan/report.c:409
       __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
       __dvb_frontend_free+0x113/0x120 drivers/media/dvb-core/dvb_frontend.c:156
       dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
       dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
       dvb_usb_adapter_frontend_exit+0xd6/0x160 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
       dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
       dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
       dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
       usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
       __device_release_driver drivers/base/dd.c:861
       device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
       device_release_driver+0x1e/0x30 drivers/base/dd.c:918
       bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
       device_del+0x5c4/0xab0 drivers/base/core.c:1985
       usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
       usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
       hub_port_connect drivers/usb/core/hub.c:4754
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x363/0x440 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      
      Allocated by task 24:
       save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
       kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
       kmalloc ./include/linux/slab.h:493
       kzalloc ./include/linux/slab.h:666
       dtt200u_fe_attach+0x4c/0x110 drivers/media/usb/dvb-usb/dtt200u-fe.c:212
       dtt200u_frontend_attach+0x35/0x80 drivers/media/usb/dvb-usb/dtt200u.c:136
       dvb_usb_adapter_frontend_init+0x32b/0x660 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
       dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
       dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
       dvb_usb_device_init+0xf73/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
       dtt200u_usb_probe+0xa1/0xe0 drivers/media/usb/dvb-usb/dtt200u.c:155
       usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
       really_probe drivers/base/dd.c:413
       driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
       __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
       bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
       __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
       device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
       bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
       device_add+0xd0b/0x1660 drivers/base/core.c:1835
       usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
       generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
       usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
       really_probe drivers/base/dd.c:413
       driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
       __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
       bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
       __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
       device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
       bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
       device_add+0xd0b/0x1660 drivers/base/core.c:1835
       usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
       hub_port_connect drivers/usb/core/hub.c:4903
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x363/0x440 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      
      Freed by task 24:
       save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459
       kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
       slab_free_hook mm/slub.c:1390
       slab_free_freelist_hook mm/slub.c:1412
       slab_free mm/slub.c:2988
       kfree+0xf6/0x2f0 mm/slub.c:3919
       dtt200u_fe_release+0x3c/0x50 drivers/media/usb/dvb-usb/dtt200u-fe.c:202
       dvb_frontend_invoke_release.part.13+0x1c/0x30 drivers/media/dvb-core/dvb_frontend.c:2790
       dvb_frontend_invoke_release drivers/media/dvb-core/dvb_frontend.c:2789
       __dvb_frontend_free+0xad/0x120 drivers/media/dvb-core/dvb_frontend.c:153
       dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
       dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
       dvb_usb_adapter_frontend_exit+0xd6/0x160 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
       dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
       dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
       dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
       usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
       __device_release_driver drivers/base/dd.c:861
       device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
       device_release_driver+0x1e/0x30 drivers/base/dd.c:918
       bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
       device_del+0x5c4/0xab0 drivers/base/core.c:1985
       usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
       usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
       hub_port_connect drivers/usb/core/hub.c:4754
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x363/0x440 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      
      The buggy address belongs to the object at ffff880067d45500
       which belongs to the cache kmalloc-2048 of size 2048
      The buggy address is located 1280 bytes inside of
       2048-byte region [ffff880067d45500, ffff880067d45d00)
      The buggy address belongs to the page:
      page:ffffea00019f5000 count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x100000000008100(slab|head)
      raw: 0100000000008100 0000000000000000 0000000000000000 00000001000f000f
      raw: dead000000000100 dead000000000200 ffff88006c002d80 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff880067d45900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880067d45980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880067d45a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff880067d45a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880067d45b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: ead66600
      
       ("media: dvb_frontend: only use kref after initialized")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Suggested-by: default avatarMatthias Schwarzott <zzam@gentoo.org>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bc8eb30
    • Daniel Scheller's avatar
      media: dvb-core: always call invoke_release() in fe_free() · ce344631
      Daniel Scheller authored
      commit 62229de1 upstream.
      
      Follow-up to: ead66600 ("media: dvb_frontend: only use kref after initialized")
      
      The aforementioned commit fixed refcount OOPSes when demod driver attaching
      succeeded but tuner driver didn't. However, the use count of the attached
      demod drivers don't go back to zero and thus couldn't be cleanly unloaded.
      Improve on this by calling dvb_frontend_invoke_release() in
      __dvb_frontend_free() regardless of fepriv being NULL, instead of returning
      when fepriv is NULL. This is safe to do since _invoke_release() will check
      for passed pointers being valid before calling the .release() function.
      
      [mchehab@s-opensource.com: changed the logic a little bit to reduce
       conflicts with another bug fix patch under review]
      Fixes: ead66600
      
       ("media: dvb_frontend: only use kref after initialized")
      Signed-off-by: default avatarDaniel Scheller <d.scheller@gmx.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce344631
    • Reinette Chatre's avatar
      x86/intel_rdt: Fix potential deadlock during resctrl unmount · 93e2d845
      Reinette Chatre authored
      
      [ Upstream commit 36b6f9fc
      
       ]
      
      Lockdep warns about a potential deadlock:
      
      [   66.782842] ======================================================
      [   66.782888] WARNING: possible circular locking dependency detected
      [   66.782937] 4.14.0-rc2-test-test+ #48 Not tainted
      [   66.782983] ------------------------------------------------------
      [   66.783052] umount/336 is trying to acquire lock:
      [   66.783117]  (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff81032395>] rdt_kill_sb+0x215/0x390
      [   66.783193]
                     but task is already holding lock:
      [   66.783244]  (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390
      [   66.783305]
                     which lock already depends on the new lock.
      
      [   66.783364]
                     the existing dependency chain (in reverse order) is:
      [   66.783419]
                     -> #3 (rdtgroup_mutex){+.+.}:
      [   66.783467]        __lock_acquire+0x1293/0x13f0
      [   66.783509]        lock_acquire+0xaf/0x220
      [   66.783543]        __mutex_lock+0x71/0x9b0
      [   66.783575]        mutex_lock_nested+0x1b/0x20
      [   66.783610]        intel_rdt_online_cpu+0x3b/0x430
      [   66.783649]        cpuhp_invoke_callback+0xab/0x8e0
      [   66.783687]        cpuhp_thread_fun+0x7a/0x150
      [   66.783722]        smpboot_thread_fn+0x1cc/0x270
      [   66.783764]        kthread+0x16e/0x190
      [   66.783794]        ret_from_fork+0x27/0x40
      [   66.783825]
                     -> #2 (cpuhp_state){+.+.}:
      [   66.783870]        __lock_acquire+0x1293/0x13f0
      [   66.783906]        lock_acquire+0xaf/0x220
      [   66.783938]        cpuhp_issue_call+0x102/0x170
      [   66.783974]        __cpuhp_setup_state_cpuslocked+0x154/0x2a0
      [   66.784023]        __cpuhp_setup_state+0xc7/0x170
      [   66.784061]        page_writeback_init+0x43/0x67
      [   66.784097]        pagecache_init+0x43/0x4a
      [   66.784131]        start_kernel+0x3ad/0x3f7
      [   66.784165]        x86_64_start_reservations+0x2a/0x2c
      [   66.784204]        x86_64_start_kernel+0x72/0x75
      [   66.784241]        verify_cpu+0x0/0xfb
      [   66.784270]
                     -> #1 (cpuhp_state_mutex){+.+.}:
      [   66.784319]        __lock_acquire+0x1293/0x13f0
      [   66.784355]        lock_acquire+0xaf/0x220
      [   66.784387]        __mutex_lock+0x71/0x9b0
      [   66.784419]        mutex_lock_nested+0x1b/0x20
      [   66.784454]        __cpuhp_setup_state_cpuslocked+0x52/0x2a0
      [   66.784497]        __cpuhp_setup_state+0xc7/0x170
      [   66.784535]        page_alloc_init+0x28/0x30
      [   66.784569]        start_kernel+0x148/0x3f7
      [   66.784602]        x86_64_start_reservations+0x2a/0x2c
      [   66.784642]        x86_64_start_kernel+0x72/0x75
      [   66.784678]        verify_cpu+0x0/0xfb
      [   66.784707]
                     -> #0 (cpu_hotplug_lock.rw_sem){++++}:
      [   66.784759]        check_prev_add+0x32f/0x6e0
      [   66.784794]        __lock_acquire+0x1293/0x13f0
      [   66.784830]        lock_acquire+0xaf/0x220
      [   66.784863]        cpus_read_lock+0x3d/0xb0
      [   66.784896]        rdt_kill_sb+0x215/0x390
      [   66.784930]        deactivate_locked_super+0x3e/0x70
      [   66.784968]        deactivate_super+0x40/0x60
      [   66.785003]        cleanup_mnt+0x3f/0x80
      [   66.785034]        __cleanup_mnt+0x12/0x20
      [   66.785070]        task_work_run+0x8b/0xc0
      [   66.785103]        exit_to_usermode_loop+0x94/0xa0
      [   66.786804]        syscall_return_slowpath+0xe8/0x150
      [   66.788502]        entry_SYSCALL_64_fastpath+0xab/0xad
      [   66.790194]
                     other info that might help us debug this:
      
      [   66.795139] Chain exists of:
                       cpu_hotplug_lock.rw_sem --> cpuhp_state --> rdtgroup_mutex
      
      [   66.800035]  Possible unsafe locking scenario:
      
      [   66.803267]        CPU0                    CPU1
      [   66.804867]        ----                    ----
      [   66.806443]   lock(rdtgroup_mutex);
      [   66.808002]                                lock(cpuhp_state);
      [   66.809565]                                lock(rdtgroup_mutex);
      [   66.811110]   lock(cpu_hotplug_lock.rw_sem);
      [   66.812608]
                      *** DEADLOCK ***
      
      [   66.816983] 2 locks held by umount/336:
      [   66.818418]  #0:  (&type->s_umount_key#35){+.+.}, at: [<ffffffff81229738>] deactivate_super+0x38/0x60
      [   66.819922]  #1:  (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390
      
      When the resctrl filesystem is unmounted the locks should be obtain in the
      locks in the same order as was done when the cpus came online:
      
            cpu_hotplug_lock before rdtgroup_mutex.
      
      This also requires to switch the static_branch_disable() calls to the
      _cpulocked variant because now cpu hotplug lock is held already.
      
      [ tglx: Switched to cpus_read_[un]lock ]
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Acked-by: default avatarVikas Shivappa <vikas.shivappa@linux.intel.com>
      Acked-by: default avatarFenghua Yu <fenghua.yu@intel.com>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Link: https://lkml.kernel.org/r/cc292e76be073f7260604651711c47b09fd0dc81.1508490116.git.reinette.chatre@intel.com
      
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93e2d845
    • Leon Romanovsky's avatar
      RDMA/cxgb4: Annotate r2 and stag as __be32 · f0a7d7b4
      Leon Romanovsky authored
      
      [ Upstream commit 7d7d065a
      
       ]
      
      Chelsio cxgb4 HW is big-endian, hence there is need to properly
      annotate r2 and stag fields as __be32 and not __u32 to fix the
      following sparse warnings.
      
        drivers/infiniband/hw/cxgb4/qp.c:614:16:
          warning: incorrect type in assignment (different base types)
            expected unsigned int [unsigned] [usertype] r2
            got restricted __be32 [usertype] <noident>
        drivers/infiniband/hw/cxgb4/qp.c:615:18:
          warning: incorrect type in assignment (different base types)
            expected unsigned int [unsigned] [usertype] stag
            got restricted __be32 [usertype] <noident>
      
      Cc: Steve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Reviewed-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0a7d7b4
    • Zdenek Kabelac's avatar
      md: free unused memory after bitmap resize · 89a459e0
      Zdenek Kabelac authored
      
      [ Upstream commit 0868b99c
      
       ]
      
      When bitmap is resized, the old kalloced chunks just are not released
      once the resized bitmap starts to use new space.
      
      This fixes in particular kmemleak reports like this one:
      
      unreferenced object 0xffff8f4311e9c000 (size 4096):
        comm "lvm", pid 19333, jiffies 4295263268 (age 528.265s)
        hex dump (first 32 bytes):
          02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80  ................
          02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80  ................
        backtrace:
          [<ffffffffa69471ca>] kmemleak_alloc+0x4a/0xa0
          [<ffffffffa628c10e>] kmem_cache_alloc_trace+0x14e/0x2e0
          [<ffffffffa676cfec>] bitmap_checkpage+0x7c/0x110
          [<ffffffffa676d0c5>] bitmap_get_counter+0x45/0xd0
          [<ffffffffa676d6b3>] bitmap_set_memory_bits+0x43/0xe0
          [<ffffffffa676e41c>] bitmap_init_from_disk+0x23c/0x530
          [<ffffffffa676f1ae>] bitmap_load+0xbe/0x160
          [<ffffffffc04c47d3>] raid_preresume+0x203/0x2f0 [dm_raid]
          [<ffffffffa677762f>] dm_table_resume_targets+0x4f/0xe0
          [<ffffffffa6774b52>] dm_resume+0x122/0x140
          [<ffffffffa6779b9f>] dev_suspend+0x18f/0x290
          [<ffffffffa677a3a7>] ctl_ioctl+0x287/0x560
          [<ffffffffa677a693>] dm_ctl_ioctl+0x13/0x20
          [<ffffffffa62d6b46>] do_vfs_ioctl+0xa6/0x750
          [<ffffffffa62d7269>] SyS_ioctl+0x79/0x90
          [<ffffffffa6956d41>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Signed-off-by: default avatarZdenek Kabelac <zkabelac@redhat.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89a459e0