1. 01 Oct, 2020 40 commits
    • Qiujun Huang's avatar
      ext4: fix a data race at inode->i_disksize · 47c5fa5b
      Qiujun Huang authored
      [ Upstream commit dce8e237 ]
      
      KCSAN find inode->i_disksize could be accessed concurrently.
      
      BUG: KCSAN: data-race in ext4_mark_iloc_dirty / ext4_write_end
      
      write (marked) to 0xffff8b8932f40090 of 8 bytes by task 66792 on cpu 0:
       ext4_write_end+0x53f/0x5b0
       ext4_da_write_end+0x237/0x510
       generic_perform_write+0x1c4/0x2a0
       ext4_buffered_write_iter+0x13a/0x210
       ext4_file_write_iter+0xe2/0x9b0
       new_sync_write+0x29c/0x3a0
       __vfs_write+0x92/0xa0
       vfs_write+0xfc/0x2a0
       ksys_write+0xe8/0x140
       __x64_sys_write+0x4c/0x60
       do_syscall_64+0x8a/0x2a0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      read to 0xffff8b8932f40090 of 8 bytes by task 14414 on cpu 1:
       ext4_mark_iloc_dirty+0x716/0x1190
       ext4_mark_inode_dirty+0xc9/0x360
       ext4_convert_unwritten_extents+0x1bc/0x2a0
       ext4_convert_unwritten_io_end_vec+0xc5/0x150
       ext4_put_io_end+0x82/0x130
       ext4_writepages+0xae7/0x16f0
       do_writepages+0x64/0x120
       __writeback_single_inode+0x7d/0x650
       writeback_sb_inodes+0x3a4/0x860
       __writeback_inodes_wb+0xc4/0x150
       wb_writeback+0x43f/0x510
       wb_workfn+0x3b2/0x8a0
       process_one_work+0x39b/0x7e0
       worker_thread+0x88/0x650
       kthread+0x1d4/0x1f0
       ret_from_fork+0x35/0x40
      
      The plain read is outside of inode->i_data_sem critical section
      which results in a data race. Fix it by adding READ_ONCE().
      Signed-off-by: default avatarQiujun Huang <hqjagain@gmail.com>
      Link: https://lore.kernel.org/r/1582556566-3909-1-git-send-email-hqjagain@gmail.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      47c5fa5b
    • Wen Yang's avatar
      timekeeping: Prevent 32bit truncation in scale64_check_overflow() · 627b771b
      Wen Yang authored
      [ Upstream commit 4cbbc3a0 ]
      
      While unlikely the divisor in scale64_check_overflow() could be >= 32bit in
      scale64_check_overflow(). do_div() truncates the divisor to 32bit at least
      on 32bit platforms.
      
      Use div64_u64() instead to avoid the truncation to 32-bit.
      
      [ tglx: Massaged changelog ]
      Signed-off-by: default avatarWen Yang <wenyang@linux.alibaba.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20200120100523.45656-1-wenyang@linux.alibaba.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      627b771b
    • Alain Michaud's avatar
      Bluetooth: guard against controllers sending zero'd events · 1ee3da6b
      Alain Michaud authored
      [ Upstream commit 08bb4da9 ]
      
      Some controllers have been observed to send zero'd events under some
      conditions.  This change guards against this condition as well as adding
      a trace to facilitate diagnosability of this condition.
      Signed-off-by: default avatarAlain Michaud <alainm@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ee3da6b
    • Takashi Iwai's avatar
      media: go7007: Fix URB type for interrupt handling · 8910d3f0
      Takashi Iwai authored
      [ Upstream commit a3ea410c ]
      
      Josef reported that his old-and-good Plextor ConvertX M402U video
      converter spews lots of WARNINGs on the recent kernels, and it turned
      out that the device uses a bulk endpoint for interrupt handling just
      like 2250 board.
      
      For fixing it, generalize the check with the proper verification of
      the endpoint instead of hard-coded board type check.
      
      Fixes: 7e5219d1 ("[media] go7007: Fix 2250 urb type")
      Reported-and-tested-by: default avatarJosef Möllers <josef.moellers@suse.com>
      BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1162583
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206427Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8910d3f0
    • John Garry's avatar
      bus: hisi_lpc: Fixup IO ports addresses to avoid use-after-free in host removal · 4ba1aee1
      John Garry authored
      [ Upstream commit a6dd255b ]
      
      Some released ACPI FW for Huawei boards describes incorrect the port IO
      address range for child devices, in that it tells us the IO port max range
      is 0x3fff for each child device, which is not correct. The address range
      should be [e4:e8) or similar. With this incorrect upper range, the child
      device IO port resources overlap.
      
      As such, the kernel thinks that the LPC host serial device is a child of
      the IPMI device:
      
      root@(none)$ more /proc/ioports
      [...]
      00ffc0e3-00ffffff : hisi-lpc-ipmi.0.auto
        00ffc0e3-00ffc0e3 : ipmi_si
        00ffc0e4-00ffc0e4 : ipmi_si
        00ffc0e5-00ffc0e5 : ipmi_si
        00ffc2f7-00ffffff : serial8250.1.auto
          00ffc2f7-00ffc2fe : serial
      root@(none)$
      
      They should both be siblings. Note that these are logical PIO addresses,
      which have a direct mapping from the FW IO port ranges.
      
      This shows up as a real issue when we enable CONFIG_KASAN and
      CONFIG_DEBUG_TEST_DRIVER_REMOVE - we see use-after-free warnings in the
      host removal path:
      
      ==================================================================
      BUG: KASAN: use-after-free in release_resource+0x38/0xc8
      Read of size 8 at addr ffff0026accdbc38 by task swapper/0/1
      
      CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00001-g68e186e77b5c-dirty #1593
      Hardware name: Huawei Taishan 2180 /D03, BIOS Hisilicon D03 IT20 Nemo 2.0 RC0 03/30/2018
      Call trace:
      dump_backtrace+0x0/0x290
      show_stack+0x14/0x20
      dump_stack+0xf0/0x14c
      print_address_description.isra.9+0x6c/0x3b8
      __kasan_report+0x12c/0x23c
      kasan_report+0xc/0x18
      __asan_load8+0x94/0xb8
      release_resource+0x38/0xc8
      platform_device_del.part.10+0x80/0xe0
      platform_device_unregister+0x20/0x38
      hisi_lpc_acpi_remove_subdev+0x10/0x20
      device_for_each_child+0xc8/0x128
      hisi_lpc_acpi_remove+0x4c/0xa8
      hisi_lpc_remove+0xbc/0xc0
      platform_drv_remove+0x3c/0x68
      really_probe+0x174/0x548
      driver_probe_device+0x7c/0x148
      device_driver_attach+0x94/0xa0
      __driver_attach+0xa4/0x110
      bus_for_each_dev+0xe8/0x158
      driver_attach+0x30/0x40
      bus_add_driver+0x234/0x2f0
      driver_register+0xbc/0x1d0
      __platform_driver_register+0x7c/0x88
      hisi_lpc_driver_init+0x18/0x20
      do_one_initcall+0xb4/0x258
      kernel_init_freeable+0x248/0x2c0
      kernel_init+0x10/0x118
      ret_from_fork+0x10/0x1c
      
      ...
      
      The issue here is that the kernel created an incorrect parent-child
      resource dependency between two devices, and references the false parent
      node when deleting the second child device, when it had been deleted
      already.
      
      Fix up the child device resources from FW to create proper IO port
      resource relationships for broken FW.
      
      With this, the IO port layout looks more healthy:
      
      root@(none)$ more /proc/ioports
      [...]
      00ffc0e3-00ffc0e7 : hisi-lpc-ipmi.0.auto
        00ffc0e3-00ffc0e3 : ipmi_si
        00ffc0e4-00ffc0e4 : ipmi_si
        00ffc0e5-00ffc0e5 : ipmi_si
      00ffc2f7-00ffc2ff : serial8250.1.auto
        00ffc2f7-00ffc2fe : serial
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarWei Xu <xuwei5@hisilicon.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4ba1aee1
    • Qian Cai's avatar
      random: fix data races at timer_rand_state · dca75ae6
      Qian Cai authored
      [ Upstream commit e00d996a ]
      
      Fields in "struct timer_rand_state" could be accessed concurrently.
      Lockless plain reads and writes result in data races. Fix them by adding
      pairs of READ|WRITE_ONCE(). The data races were reported by KCSAN,
      
       BUG: KCSAN: data-race in add_timer_randomness / add_timer_randomness
      
       write to 0xffff9f320a0a01d0 of 8 bytes by interrupt on cpu 22:
        add_timer_randomness+0x100/0x190
        add_timer_randomness at drivers/char/random.c:1152
        add_disk_randomness+0x85/0x280
        scsi_end_request+0x43a/0x4a0
        scsi_io_completion+0xb7/0x7e0
        scsi_finish_command+0x1ed/0x2a0
        scsi_softirq_done+0x1c9/0x1d0
        blk_done_softirq+0x181/0x1d0
        __do_softirq+0xd9/0x57c
        irq_exit+0xa2/0xc0
        do_IRQ+0x8b/0x190
        ret_from_intr+0x0/0x42
        cpuidle_enter_state+0x15e/0x980
        cpuidle_enter+0x69/0xc0
        call_cpuidle+0x23/0x40
        do_idle+0x248/0x280
        cpu_startup_entry+0x1d/0x1f
        start_secondary+0x1b2/0x230
        secondary_startup_64+0xb6/0xc0
      
       no locks held by swapper/22/0.
       irq event stamp: 32871382
       _raw_spin_unlock_irqrestore+0x53/0x60
       _raw_spin_lock_irqsave+0x21/0x60
       _local_bh_enable+0x21/0x30
       irq_exit+0xa2/0xc0
      
       read to 0xffff9f320a0a01d0 of 8 bytes by interrupt on cpu 2:
        add_timer_randomness+0xe8/0x190
        add_disk_randomness+0x85/0x280
        scsi_end_request+0x43a/0x4a0
        scsi_io_completion+0xb7/0x7e0
        scsi_finish_command+0x1ed/0x2a0
        scsi_softirq_done+0x1c9/0x1d0
        blk_done_softirq+0x181/0x1d0
        __do_softirq+0xd9/0x57c
        irq_exit+0xa2/0xc0
        do_IRQ+0x8b/0x190
        ret_from_intr+0x0/0x42
        cpuidle_enter_state+0x15e/0x980
        cpuidle_enter+0x69/0xc0
        call_cpuidle+0x23/0x40
        do_idle+0x248/0x280
        cpu_startup_entry+0x1d/0x1f
        start_secondary+0x1b2/0x230
        secondary_startup_64+0xb6/0xc0
      
       no locks held by swapper/2/0.
       irq event stamp: 37846304
       _raw_spin_unlock_irqrestore+0x53/0x60
       _raw_spin_lock_irqsave+0x21/0x60
       _local_bh_enable+0x21/0x30
       irq_exit+0xa2/0xc0
      
       Reported by Kernel Concurrency Sanitizer on:
       Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018
      
      Link: https://lore.kernel.org/r/1582648024-13111-1-git-send-email-cai@lca.pwSigned-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dca75ae6
    • James Morse's avatar
      firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhp · f674193b
      James Morse authored
      [ Upstream commit 54f529a6 ]
      
      SDEI has private events that need registering and enabling on each CPU.
      CPUs can come and go while we are trying to do this. SDEI tries to avoid
      these problems by setting the reregister flag before the register call,
      so any CPUs that come online register the event too. Sticking plaster
      like this doesn't work, as if the register call fails, a CPU that
      subsequently comes online will register the event before reregister
      is cleared.
      
      Take cpus_read_lock() around the register and enable calls. We don't
      want surprise CPUs to do the wrong thing if they race with these calls
      failing.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f674193b
    • Aric Cyr's avatar
      drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic · 5fe40ed2
      Aric Cyr authored
      [ Upstream commit 6a6c4a4d ]
      
      [Why]
      Since the i2c payload allocation can fail need to check return codes
      
      [How]
      Clean up i2c payload allocations and check for errors
      Signed-off-by: default avatarAric Cyr <aric.cyr@amd.com>
      Reviewed-by: default avatarJoshua Aberback <Joshua.Aberback@amd.com>
      Acked-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Acked-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5fe40ed2
    • Dmitry Osipenko's avatar
      dmaengine: tegra-apb: Prevent race conditions on channel's freeing · 7fbd24e0
      Dmitry Osipenko authored
      [ Upstream commit 8e84172e ]
      
      It's incorrect to check the channel's "busy" state without taking a lock.
      That shouldn't cause any real troubles, nevertheless it's always better
      not to have any race conditions in the code.
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Link: https://lore.kernel.org/r/20200209163356.6439-5-digetx@gmail.comSigned-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7fbd24e0
    • Amelie Delaunay's avatar
      dmaengine: stm32-dma: use vchan_terminate_vdesc() in .terminate_all · 1da6faf4
      Amelie Delaunay authored
      [ Upstream commit d80cbef3 ]
      
      To avoid race with vchan_complete, use the race free way to terminate
      running transfer.
      
      Move vdesc->node list_del in stm32_dma_start_transfer instead of in
      stm32_mdma_chan_complete to avoid another race in vchan_dma_desc_free_list.
      Signed-off-by: default avatarAmelie Delaunay <amelie.delaunay@st.com>
      Link: https://lore.kernel.org/r/20200129153628.29329-9-amelie.delaunay@st.comSigned-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1da6faf4
    • Thomas Gleixner's avatar
      bpf: Remove recursion prevention from rcu free callback · 1baf2360
      Thomas Gleixner authored
      [ Upstream commit 8a37963c ]
      
      If an element is freed via RCU then recursion into BPF instrumentation
      functions is not a concern. The element is already detached from the map
      and the RCU callback does not hold any locks on which a kprobe, perf event
      or tracepoint attached BPF program could deadlock.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200224145643.259118710@linutronix.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      1baf2360
    • Dave Hansen's avatar
      x86/pkeys: Add check for pkey "overflow" · 03dda956
      Dave Hansen authored
      [ Upstream commit 16171bff ]
      
      Alex Shi reported the pkey macros above arch_set_user_pkey_access()
      to be unused.  They are unused, and even refer to a nonexistent
      CONFIG option.
      
      But, they might have served a good use, which was to ensure that
      the code does not try to set values that would not fit in the
      PKRU register.  As it stands, a too-large 'pkey' value would
      be likely to silently overflow the u32 new_pkru_bits.
      
      Add a check to look for overflows.  Also add a comment to remind
      any future developer to closely examine the types used to store
      pkey values if arch_max_pkey() ever changes.
      
      This boots and passes the x86 pkey selftests.
      Reported-by: default avatarAlex Shi <alex.shi@linux.alibaba.com>
      Signed-off-by: default avatarDave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/20200122165346.AD4DA150@viggo.jf.intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      03dda956
    • Dan Carpenter's avatar
      media: staging/imx: Missing assignment in imx_media_capture_device_register() · eec0eacf
      Dan Carpenter authored
      [ Upstream commit ef0ed05d ]
      
      There was supposed to be a "ret = " assignment here, otherwise the
      error handling on the next line won't work.
      
      Fixes: 64b5a49d ("[media] media: imx: Add Capture Device Interface")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarSteve Longerbeam <slongerbeam@gmail.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eec0eacf
    • Amelie Delaunay's avatar
      dmaengine: stm32-mdma: use vchan_terminate_vdesc() in .terminate_all · bb198240
      Amelie Delaunay authored
      [ Upstream commit dfc70881 ]
      
      To avoid race with vchan_complete, use the race free way to terminate
      running transfer.
      
      Move vdesc->node list_del in stm32_mdma_start_transfer instead of in
      stm32_mdma_xfer_end to avoid another race in vchan_dma_desc_free_list.
      Signed-off-by: default avatarAmelie Delaunay <amelie.delaunay@st.com>
      Link: https://lore.kernel.org/r/20200127085334.13163-7-amelie.delaunay@st.comSigned-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bb198240
    • Paolo Bonzini's avatar
      KVM: x86: fix incorrect comparison in trace event · 09ace5ea
      Paolo Bonzini authored
      [ Upstream commit 147f1a1f ]
      
      The "u" field in the event has three states, -1/0/1.  Using u8 however means that
      comparison with -1 will always fail, so change to signed char.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09ace5ea
    • Bart Van Assche's avatar
      RDMA/rxe: Fix configuration of atomic queue pair attributes · 46a57510
      Bart Van Assche authored
      [ Upstream commit fb3063d3 ]
      
      From the comment above the definition of the roundup_pow_of_two() macro:
      
           The result is undefined when n == 0.
      
      Hence only pass positive values to roundup_pow_of_two(). This patch fixes
      the following UBSAN complaint:
      
        UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13
        shift exponent 64 is too large for 64-bit type 'long unsigned int'
        Call Trace:
         dump_stack+0xa5/0xe6
         ubsan_epilogue+0x9/0x26
         __ubsan_handle_shift_out_of_bounds.cold+0x4c/0xf9
         rxe_qp_from_attr.cold+0x37/0x5d [rdma_rxe]
         rxe_modify_qp+0x59/0x70 [rdma_rxe]
         _ib_modify_qp+0x5aa/0x7c0 [ib_core]
         ib_modify_qp+0x3b/0x50 [ib_core]
         cma_modify_qp_rtr+0x234/0x260 [rdma_cm]
         __rdma_accept+0x1a7/0x650 [rdma_cm]
         nvmet_rdma_cm_handler+0x1286/0x14cd [nvmet_rdma]
         cma_cm_event_handler+0x6b/0x330 [rdma_cm]
         cma_ib_req_handler+0xe60/0x22d0 [rdma_cm]
         cm_process_work+0x30/0x140 [ib_cm]
         cm_req_handler+0x11f4/0x1cd0 [ib_cm]
         cm_work_handler+0xb8/0x344e [ib_cm]
         process_one_work+0x569/0xb60
         worker_thread+0x7a/0x5d0
         kthread+0x1e6/0x210
         ret_from_fork+0x24/0x30
      
      Link: https://lore.kernel.org/r/20200217205714.26937-1-bvanassche@acm.org
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      46a57510
    • Thomas Richter's avatar
      perf test: Fix test trace+probe_vfs_getname.sh on s390 · 345dc71a
      Thomas Richter authored
      [ Upstream commit 2bbc8353 ]
      
      This test places a kprobe to function getname_flags() in the kernel
      which has the following prototype:
      
        struct filename *getname_flags(const char __user *filename, int flags, int *empty)
      
      The 'filename' argument points to a filename located in user space memory.
      
      Looking at commit 88903c46 ("tracing/probe: Add ustring type for
      user-space string") the kprobe should indicate that user space memory is
      accessed.
      
      Output before:
      
         [root@m35lp76 perf]# ./perf test 66 67
         66: Use vfs_getname probe to get syscall args filenames   : FAILED!
         67: Check open filename arg using perf trace + vfs_getname: FAILED!
         [root@m35lp76 perf]#
      
      Output after:
      
         [root@m35lp76 perf]# ./perf test 66 67
         66: Use vfs_getname probe to get syscall args filenames   : Ok
         67: Check open filename arg using perf trace + vfs_getname: Ok
         [root@m35lp76 perf]#
      
      Comments from Masami Hiramatsu:
      
      This bug doesn't happen on x86 or other archs on which user address
      space and kernel address space is the same. On some arches (ppc64 in
      this case?) user address space is partially or completely the same as
      kernel address space.
      
      (Yes, they switch the world when running into the kernel) In this case,
      we need to use different data access functions for each space.
      
      That is why I introduced the "ustring" type for kprobe events.
      
      As far as I can see, Thomas's patch is sane. Thomas, could you show us
      your result on your test environment?
      
      Comments from Thomas Richter:
      
      Test results for s/390 included above.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Link: http://lore.kernel.org/lkml/20200217102111.61137-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      345dc71a
    • Takashi Iwai's avatar
      ALSA: usb-audio: Don't create a mixer element with bogus volume range · 0cafae90
      Takashi Iwai authored
      [ Upstream commit e9a0ef0b ]
      
      Some USB-audio descriptors provide a bogus volume range (e.g. volume
      min and max are identical), which confuses user-space.
      This patch makes the driver skipping such a control element.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206221
      Link: https://lore.kernel.org/r/20200214144928.23628-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0cafae90
    • Felix Fietkau's avatar
      mt76: clear skb pointers from rx aggregation reorder buffer during cleanup · ac6724d4
      Felix Fietkau authored
      [ Upstream commit 9379df2f ]
      
      During the cleanup of the aggregation session, a rx handler (or release timer)
      on another CPU might still hold a pointer to the reorder buffer and could
      attempt to release some packets.
      Clearing pointers during cleanup avoids a theoretical use-after-free bug here.
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ac6724d4
    • Ayush Sawal's avatar
      crypto: chelsio - This fixes the kernel panic which occurs during a libkcapi test · 7444a79b
      Ayush Sawal authored
      [ Upstream commit 9195189e ]
      
      The libkcapi test which causes kernel panic is
      aead asynchronous vmsplice multiple test.
      
      ./bin/kcapi  -v -d 4 -x 10   -c "ccm(aes)"
      -q 4edb58e8d5eb6bc711c43a6f3693daebde2e5524f1b55297abb29f003236e43d
      -t a7877c99 -n 674742abd0f5ba -k 2861fd0253705d7875c95ba8a53171b4
      -a fb7bc304a3909e66e2e0c5ef952712dd884ce3e7324171369f2c5db1adc48c7d
      
      This patch avoids dma_mapping of a zero length sg which causes the panic,
      by using sg_nents_for_len which maps only upto a specific length
      Signed-off-by: default avatarAyush Sawal <ayush.sawal@chelsio.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7444a79b
    • Dinh Nguyen's avatar
      clk: stratix10: use do_div() for 64-bit calculation · f99ca8f0
      Dinh Nguyen authored
      [ Upstream commit cc26ed7b ]
      
      do_div() macro to perform u64 division and guards against overflow if
      the result is too large for the unsigned long return type.
      Signed-off-by: default avatarDinh Nguyen <dinguyen@kernel.org>
      Link: https://lkml.kernel.org/r/20200114160726.19771-1-dinguyen@kernel.orgSigned-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f99ca8f0
    • Wen Yang's avatar
      drm/omap: fix possible object reference leak · d4c38bfb
      Wen Yang authored
      [ Upstream commit 47340e46 ]
      
      The call to of_find_matching_node returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
      drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Markus Elfring <Markus.Elfring@web.de>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      d4c38bfb
    • James Smart's avatar
      scsi: lpfc: Fix coverity errors in fmdi attribute handling · b4ba41c8
      James Smart authored
      [ Upstream commit 4cb9e1dd ]
      
      Coverity reported a memory corruption error for the fdmi attributes
      routines:
      
        CID 15768 [Memory Corruption] Out-of-bounds access on FDMI
      
      Sloppy coding of the fmdi structures. In both the lpfc_fdmi_attr_def and
      lpfc_fdmi_reg_port_list structures, a field was placed at the start of
      payload that may have variable content. The field was given an arbitrary
      type (uint32_t). The code then uses the field name to derive an address,
      which it used in things such as memset and memcpy. The memset sizes or
      memcpy lengths were larger than the arbitrary type, thus coverity reported
      an error.
      
      Fix by replacing the arbitrary fields with the real field structures
      describing the payload.
      
      Link: https://lore.kernel.org/r/20200128002312.16346-8-jsmart2021@gmail.comSigned-off-by: default avatarDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b4ba41c8
    • James Smart's avatar
      scsi: lpfc: Fix RQ buffer leakage when no IOCBs available · 1ae009aa
      James Smart authored
      [ Upstream commit 39c4f1a9 ]
      
      The driver is occasionally seeing the following SLI Port error, requiring
      reset and reinit:
      
       Port Status Event: ... error 1=0x52004a01, error 2=0x218
      
      The failure means an RQ timeout. That is, the adapter had received
      asynchronous receive frames, ran out of buffer slots to place the frames,
      and the driver did not replenish the buffer slots before a timeout
      occurred. The driver should not be so slow in replenishing buffers that a
      timeout can occur.
      
      When the driver received all the frames of a sequence, it allocates an IOCB
      to put the frames in. In a situation where there was no IOCB available for
      the frame of a sequence, the RQ buffer corresponding to the first frame of
      the sequence was not returned to the FW. Eventually, with enough traffic
      encountering the situation, the timeout occurred.
      
      Fix by releasing the buffer back to firmware whenever there is no IOCB for
      the first frame.
      
      [mkp: typo]
      
      Link: https://lore.kernel.org/r/20200128002312.16346-2-jsmart2021@gmail.comSigned-off-by: default avatarDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ae009aa
    • Vasily Averin's avatar
      selinux: sel_avc_get_stat_idx should increase position index · 64e0f9e1
      Vasily Averin authored
      [ Upstream commit 8d269a8e ]
      
      If seq_file .next function does not change position index,
      read after some lseek can generate unexpected output.
      
      $ dd if=/sys/fs/selinux/avc/cache_stats # usual output
      lookups hits misses allocations reclaims frees
      817223 810034 7189 7189 6992 7037
      1934894 1926896 7998 7998 7632 7683
      1322812 1317176 5636 5636 5456 5507
      1560571 1551548 9023 9023 9056 9115
      0+1 records in
      0+1 records out
      189 bytes copied, 5,1564e-05 s, 3,7 MB/s
      
      $# read after lseek to midle of last line
      $ dd if=/sys/fs/selinux/avc/cache_stats bs=180 skip=1
      dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset
      056 9115   <<<< end of last line
      1560571 1551548 9023 9023 9056 9115  <<< whole last line once again
      0+1 records in
      0+1 records out
      45 bytes copied, 8,7221e-05 s, 516 kB/s
      
      $# read after lseek beyond  end of of file
      $ dd if=/sys/fs/selinux/avc/cache_stats bs=1000 skip=1
      dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset
      1560571 1551548 9023 9023 9056 9115  <<<< generates whole last line
      0+1 records in
      0+1 records out
      36 bytes copied, 9,0934e-05 s, 396 kB/s
      
      https://bugzilla.kernel.org/show_bug.cgi?id=206283Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      64e0f9e1
    • Steve Grubb's avatar
      audit: CONFIG_CHANGE don't log internal bookkeeping as an event · 67fd417f
      Steve Grubb authored
      [ Upstream commit 70b3eeed ]
      
      Common Criteria calls out for any action that modifies the audit trail to
      be recorded. That usually is interpreted to mean insertion or removal of
      rules. It is not required to log modification of the inode information
      since the watch is still in effect. Additionally, if the rule is a never
      rule and the underlying file is one they do not want events for, they
      get an event for this bookkeeping update against their wishes.
      
      Since no device/inode info is logged at insertion and no device/inode
      information is logged on update, there is nothing meaningful being
      communicated to the admin by the CONFIG_CHANGE updated_rules event. One
      can assume that the rule was not "modified" because it is still watching
      the intended target. If the device or inode cannot be resolved, then
      audit_panic is called which is sufficient.
      
      The correct resolution is to drop logging config_update events since
      the watch is still in effect but just on another unknown inode.
      Signed-off-by: default avatarSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      67fd417f
    • Qian Cai's avatar
      skbuff: fix a data race in skb_queue_len() · 1fea0234
      Qian Cai authored
      [ Upstream commit 86b18aaa ]
      
      sk_buff.qlen can be accessed concurrently as noticed by KCSAN,
      
       BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_dgram_sendmsg
      
       read to 0xffff8a1b1d8a81c0 of 4 bytes by task 5371 on cpu 96:
        unix_dgram_sendmsg+0x9a9/0xb70 include/linux/skbuff.h:1821
      				 net/unix/af_unix.c:1761
        ____sys_sendmsg+0x33e/0x370
        ___sys_sendmsg+0xa6/0xf0
        __sys_sendmsg+0x69/0xf0
        __x64_sys_sendmsg+0x51/0x70
        do_syscall_64+0x91/0xb47
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       write to 0xffff8a1b1d8a81c0 of 4 bytes by task 1 on cpu 99:
        __skb_try_recv_from_queue+0x327/0x410 include/linux/skbuff.h:2029
        __skb_try_recv_datagram+0xbe/0x220
        unix_dgram_recvmsg+0xee/0x850
        ____sys_recvmsg+0x1fb/0x210
        ___sys_recvmsg+0xa2/0xf0
        __sys_recvmsg+0x66/0xf0
        __x64_sys_recvmsg+0x51/0x70
        do_syscall_64+0x91/0xb47
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Since only the read is operating as lockless, it could introduce a logic
      bug in unix_recvq_full() due to the load tearing. Fix it by adding
      a lockless variant of skb_queue_len() and unix_recvq_full() where
      READ_ONCE() is on the read while WRITE_ONCE() is on the write similar to
      the commit d7d16a89 ("net: add skb_queue_empty_lockless()").
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1fea0234
    • Mohan Kumar's avatar
      ALSA: hda: Clear RIRB status before reading WP · 63cf8e58
      Mohan Kumar authored
      [ Upstream commit 6d011d50 ]
      
      RIRB interrupt status getting cleared after the write pointer is read
      causes a race condition, where last response(s) into RIRB may remain
      unserviced by IRQ, eventually causing azx_rirb_get_response to fall
      back to polling mode. Clearing the RIRB interrupt status ahead of
      write pointer access ensures that this condition is avoided.
      Signed-off-by: default avatarMohan Kumar <mkumard@nvidia.com>
      Signed-off-by: default avatarViswanath L <viswanathl@nvidia.com>
      Link: https://lore.kernel.org/r/1580983853-351-1-git-send-email-viswanathl@nvidia.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      63cf8e58
    • Zhuang Yanying's avatar
      KVM: fix overflow of zero page refcount with ksm running · 58f79f42
      Zhuang Yanying authored
      [ Upstream commit 7df003c8 ]
      
      We are testing Virtual Machine with KSM on v5.4-rc2 kernel,
      and found the zero_page refcount overflow.
      The cause of refcount overflow is increased in try_async_pf
      (get_user_page) without being decreased in mmu_set_spte()
      while handling ept violation.
      In kvm_release_pfn_clean(), only unreserved page will call
      put_page. However, zero page is reserved.
      So, as well as creating and destroy vm, the refcount of
      zero page will continue to increase until it overflows.
      
      step1:
      echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan
      echo 1 > /sys/kernel/pages_to_scan/run
      echo 1 > /sys/kernel/pages_to_scan/use_zero_pages
      
      step2:
      just create several normal qemu kvm vms.
      And destroy it after 10s.
      Repeat this action all the time.
      
      After a long period of time, all domains hang because
      of the refcount of zero page overflow.
      
      Qemu print error log as follow:
       …
       error: kvm run failed Bad address
       EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd
       ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4
       EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
       ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
       SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
       TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
       GDT=     000f7070 00000037
       IDT=     000f70ae 00000000
       CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
       DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
       DR6=00000000ffff0ff0 DR7=0000000000000400
       EFER=0000000000000000
       Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04
       …
      
      Meanwhile, a kernel warning is departed.
      
       [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30
       [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G           OE     5.2.0-rc2 #5
       [40914.836415] RIP: 0010:try_get_page+0x1f/0x30
       [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0
       0 00 00 00 48 8b 47 08 a8
       [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286
       [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000
       [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440
       [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000
       [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8
       [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440
       [40914.836423] FS:  00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000
       [40914.836425] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0
       [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       [40914.836428] Call Trace:
       [40914.836433]  follow_page_pte+0x302/0x47b
       [40914.836437]  __get_user_pages+0xf1/0x7d0
       [40914.836441]  ? irq_work_queue+0x9/0x70
       [40914.836443]  get_user_pages_unlocked+0x13f/0x1e0
       [40914.836469]  __gfn_to_pfn_memslot+0x10e/0x400 [kvm]
       [40914.836486]  try_async_pf+0x87/0x240 [kvm]
       [40914.836503]  tdp_page_fault+0x139/0x270 [kvm]
       [40914.836523]  kvm_mmu_page_fault+0x76/0x5e0 [kvm]
       [40914.836588]  vcpu_enter_guest+0xb45/0x1570 [kvm]
       [40914.836632]  kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm]
       [40914.836645]  kvm_vcpu_ioctl+0x26e/0x5d0 [kvm]
       [40914.836650]  do_vfs_ioctl+0xa9/0x620
       [40914.836653]  ksys_ioctl+0x60/0x90
       [40914.836654]  __x64_sys_ioctl+0x16/0x20
       [40914.836658]  do_syscall_64+0x5b/0x180
       [40914.836664]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
       [40914.836666] RIP: 0033:0x7fb61cb6bfc7
      Signed-off-by: default avatarLinFeng <linfeng23@huawei.com>
      Signed-off-by: default avatarZhuang Yanying <ann.zhuangyanying@huawei.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      58f79f42
    • Hillf Danton's avatar
      Bluetooth: prefetch channel before killing sock · 4b0795d5
      Hillf Danton authored
      [ Upstream commit 2a154903 ]
      
      Prefetch channel before killing sock in order to fix UAF like
      
       BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290 net/bluetooth/l2cap_sock.c:1212
       Read of size 8 at addr ffff8880944904a0 by task syz-fuzzer/9751
      
      Reported-by: syzbot+c3c5bdea7863886115dc@syzkaller.appspotmail.com
      Fixes: 6c08fc89 ("Bluetooth: Fix refcount use-after-free issue")
      Cc: Manish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4b0795d5
    • Steven Price's avatar
      mm: pagewalk: fix termination condition in walk_pte_range() · f9cb6b61
      Steven Price authored
      [ Upstream commit c02a9875 ]
      
      If walk_pte_range() is called with a 'end' argument that is beyond the
      last page of memory (e.g.  ~0UL) then the comparison between 'addr' and
      'end' will always fail and the loop will be infinite.  Instead change the
      comparison to >= while accounting for overflow.
      
      Link: http://lkml.kernel.org/r/20191218162402.45610-15-steven.price@arm.comSigned-off-by: default avatarSteven Price <steven.price@arm.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexandre Ghiti <alex@ghiti.fr>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: "Liang, Kan" <kan.liang@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Zong Li <zong.li@sifive.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 avatarSasha Levin <sashal@kernel.org>
      f9cb6b61
    • Vasily Averin's avatar
      mm/swapfile.c: swap_next should increase position index · 52f5a09a
      Vasily Averin authored
      [ Upstream commit 10c8d69f ]
      
      If seq_file .next fuction does not change position index, read after
      some lseek can generate unexpected output.
      
      In Aug 2018 NeilBrown noticed commit 1f4aace6 ("fs/seq_file.c:
      simplify seq_file iteration code and interface") "Some ->next functions
      do not increment *pos when they return NULL...  Note that such ->next
      functions are buggy and should be fixed.  A simple demonstration is
      
        dd if=/proc/swaps bs=1000 skip=1
      
      Choose any block size larger than the size of /proc/swaps.  This will
      always show the whole last line of /proc/swaps"
      
      Described problem is still actual.  If you make lseek into middle of
      last output line following read will output end of last line and whole
      last line once again.
      
        $ dd if=/proc/swaps bs=1  # usual output
        Filename				Type		Size	Used	Priority
        /dev/dm-0                               partition	4194812	97536	-2
        104+0 records in
        104+0 records out
        104 bytes copied
      
        $ dd if=/proc/swaps bs=40 skip=1    # last line was generated twice
        dd: /proc/swaps: cannot skip to specified offset
        v/dm-0                               partition	4194812	97536	-2
        /dev/dm-0                               partition	4194812	97536	-2
        3+1 records in
        3+1 records out
        131 bytes copied
      
      https://bugzilla.kernel.org/show_bug.cgi?id=206283
      
      Link: http://lkml.kernel.org/r/bd8cfd7b-ac95-9b91-f9e7-e8438bd5047d@virtuozzo.comSigned-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Hugh Dickins <hughd@google.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 avatarSasha Levin <sashal@kernel.org>
      52f5a09a
    • Manish Mandlik's avatar
      Bluetooth: Fix refcount use-after-free issue · 3b73af6c
      Manish Mandlik authored
      [ Upstream commit 6c08fc89 ]
      
      There is no lock preventing both l2cap_sock_release() and
      chan->ops->close() from running at the same time.
      
      If we consider Thread A running l2cap_chan_timeout() and Thread B running
      l2cap_sock_release(), expected behavior is:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
      
      where,
      sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks
      socket as SOCK_ZAPPED.
      
      In l2cap_sock_kill(), there is an "if-statement" that checks if both
      sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL
      and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is
      satisfied.
      
      In the race condition, following occurs:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
      In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and
      A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug.
      
      Similar condition occurs at other places where teardown/sock_kill is
      happening:
        l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        l2cap_sock_cleanup_listen()->l2cap_sock_kill()
      
      Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on
      l2cap channel to ensure that the socket is killed only after marked as
      zapped and orphan.
      Signed-off-by: default avatarManish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3b73af6c
    • Doug Smythies's avatar
      tools/power/x86/intel_pstate_tracer: changes for python 3 compatibility · fd095623
      Doug Smythies authored
      [ Upstream commit e749e09d ]
      
      Some syntax needs to be more rigorous for python 3.
      Backwards compatibility tested with python 2.7
      Signed-off-by: default avatarDoug Smythies <dsmythies@telus.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fd095623
    • Sven Schnelle's avatar
      selftests/ftrace: fix glob selftest · b3c93091
      Sven Schnelle authored
      [ Upstream commit af4ddd60 ]
      
      test.d/ftrace/func-filter-glob.tc is failing on s390 because it has
      ARCH_INLINE_SPIN_LOCK and friends set to 'y'. So the usual
      __raw_spin_lock symbol isn't in the ftrace function list. Change
      '*aw*lock' to '*spin*lock' which would hopefully match some of the
      locking functions on all platforms.
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSven Schnelle <svens@linux.ibm.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b3c93091
    • Jeff Layton's avatar
      ceph: ensure we have a new cap before continuing in fill_inode · 4d9cf934
      Jeff Layton authored
      [ Upstream commit 9a6bed4f ]
      
      If the caller passes in a NULL cap_reservation, and we can't allocate
      one then ensure that we fail gracefully.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4d9cf934
    • Mert Dirik's avatar
      ar5523: Add USB ID of SMCWUSBT-G2 wireless adapter · a567bac1
      Mert Dirik authored
      [ Upstream commit 5b362498 ]
      
      Add the required USB ID for running SMCWUSBT-G2 wireless adapter (SMC
      "EZ Connect g").
      
      This device uses ar5523 chipset and requires firmware to be loaded. Even
      though pid of the device is 4507, this patch adds it as 4506 so that
      AR5523_DEVICE_UG macro can set the AR5523_FLAG_PRE_FIRMWARE flag for pid
      4507.
      Signed-off-by: default avatarMert Dirik <mertdirik@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a567bac1
    • Vincent Whitchurch's avatar
      ARM: 8948/1: Prevent OOB access in stacktrace · cd0c2804
      Vincent Whitchurch authored
      [ Upstream commit 40ff1ddb ]
      
      The stacktrace code can read beyond the stack size, when it attempts to
      read pt_regs from exception frames.
      
      This can happen on normal, non-corrupt stacks.  Since the unwind
      information in the extable is not correct for function prologues, the
      unwinding code can return data from the stack which is not actually the
      caller function address, and if in_entry_text() happens to succeed on
      this value, we can end up reading data from outside the task's stack
      when attempting to read pt_regs, since there is no bounds check.
      
      Example:
      
       [<8010e729>] (unwind_backtrace) from [<8010a9c9>] (show_stack+0x11/0x14)
       [<8010a9c9>] (show_stack) from [<8057d8d7>] (dump_stack+0x87/0xac)
       [<8057d8d7>] (dump_stack) from [<8012271d>] (tasklet_action_common.constprop.4+0xa5/0xa8)
       [<8012271d>] (tasklet_action_common.constprop.4) from [<80102333>] (__do_softirq+0x11b/0x31c)
       [<80102333>] (__do_softirq) from [<80122485>] (irq_exit+0xad/0xd8)
       [<80122485>] (irq_exit) from [<8015f3d7>] (__handle_domain_irq+0x47/0x84)
       [<8015f3d7>] (__handle_domain_irq) from [<8036a523>] (gic_handle_irq+0x43/0x78)
       [<8036a523>] (gic_handle_irq) from [<80101a49>] (__irq_svc+0x69/0xb4)
       Exception stack(0xeb491f58 to 0xeb491fa0)
       1f40:                                                       7eb14794 00000000
       1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
       1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
       [<80101a49>] (__irq_svc) from [<8023d09c>] (do_pipe2+0x0/0xac)
       [<8023d09c>] (do_pipe2) from [<ffffffff>] (0xffffffff)
       Exception stack(0xeb491fc8 to 0xeb492010)
       1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
       1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
       2000: 00000001 00000000 ea846c00 ea847cc0
      
      In this example, the stack limit is 0xeb492000, but 16 bytes outside the
      stack have been read.
      
      Fix it by adding bounds checks.
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd0c2804
    • Josef Bacik's avatar
      tracing: Set kernel_stack's caller size properly · 72913876
      Josef Bacik authored
      [ Upstream commit cbc3b92c ]
      
      I noticed when trying to use the trace-cmd python interface that reading the raw
      buffer wasn't working for kernel_stack events.  This is because it uses a
      stubbed version of __dynamic_array that doesn't do the __data_loc trick and
      encode the length of the array into the field.  Instead it just shows up as a
      size of 0.  So change this to __array and set the len to FTRACE_STACK_ENTRIES
      since this is what we actually do in practice and matches how user_stack_trace
      works.
      
      Link: http://lkml.kernel.org/r/1411589652-1318-1-git-send-email-jbacik@fb.comSigned-off-by: default avatarJosef Bacik <jbacik@fb.com>
      [ Pulled from the archeological digging of my INBOX ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      72913876
    • Maxim Mikityanskiy's avatar
      Bluetooth: btrtl: Use kvmalloc for FW allocations · 4d04a4da
      Maxim Mikityanskiy authored
      [ Upstream commit 268d3636 ]
      
      Currently, kmemdup is applied to the firmware data, and it invokes
      kmalloc under the hood. The firmware size and patch_length are big (more
      than PAGE_SIZE), and on some low-end systems (like ASUS E202SA) kmalloc
      may fail to allocate a contiguous chunk under high memory usage and
      fragmentation:
      
      Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000a lmp_ver=06 lmp_subver=8821
      Bluetooth: hci0: RTL: rom_version status=0 version=1
      Bluetooth: hci0: RTL: loading rtl_bt/rtl8821a_fw.bin
      kworker/u9:2: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
      <stack trace follows>
      
      As firmware load happens on each resume, Bluetooth will stop working
      after several iterations, when the kernel fails to allocate an order-4
      page.
      
      This patch replaces kmemdup with kvmalloc+memcpy. It's not required to
      have a contiguous chunk here, because it's not mapped to the device
      directly.
      Signed-off-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4d04a4da