1. 29 Sep, 2018 40 commits
    • Joel Fernandes (Google)'s avatar
      mm: shmem.c: Correctly annotate new inodes for lockdep · 946f8052
      Joel Fernandes (Google) authored
      commit b45d71fb upstream.
      
      Directories and inodes don't necessarily need to be in the same lockdep
      class.  For ex, hugetlbfs splits them out too to prevent false positives
      in lockdep.  Annotate correctly after new inode creation.  If its a
      directory inode, it will be put into a different class.
      
      This should fix a lockdep splat reported by syzbot:
      
      > ======================================================
      > WARNING: possible circular locking dependency detected
      > 4.18.0-rc8-next-20180810+ #36 Not tainted
      > ------------------------------------------------------
      > syz-executor900/4483 is trying to acquire lock:
      > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock
      > include/linux/fs.h:765 [inline]
      > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at:
      > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
      >
      > but task is already holding lock:
      > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
      > drivers/staging/android/ashmem.c:448
      >
      > which lock already depends on the new lock.
      >
      > -> #2 (ashmem_mutex){+.+.}:
      >        __mutex_lock_common kernel/locking/mutex.c:925 [inline]
      >        __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
      >        mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
      >        ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
      >        call_mmap include/linux/fs.h:1844 [inline]
      >        mmap_region+0xf27/0x1c50 mm/mmap.c:1762
      >        do_mmap+0xa10/0x1220 mm/mmap.c:1535
      >        do_mmap_pgoff include/linux/mm.h:2298 [inline]
      >        vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
      >        ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
      >        __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
      >        __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
      >        __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
      >        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      >        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      >
      > -> #1 (&mm->mmap_sem){++++}:
      >        __might_fault+0x155/0x1e0 mm/memory.c:4568
      >        _copy_to_user+0x30/0x110 lib/usercopy.c:25
      >        copy_to_user include/linux/uaccess.h:155 [inline]
      >        filldir+0x1ea/0x3a0 fs/readdir.c:196
      >        dir_emit_dot include/linux/fs.h:3464 [inline]
      >        dir_emit_dots include/linux/fs.h:3475 [inline]
      >        dcache_readdir+0x13a/0x620 fs/libfs.c:193
      >        iterate_dir+0x48b/0x5d0 fs/readdir.c:51
      >        __do_sys_getdents fs/readdir.c:231 [inline]
      >        __se_sys_getdents fs/readdir.c:212 [inline]
      >        __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
      >        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      >        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      >
      > -> #0 (&sb->s_type->i_mutex_key#9){++++}:
      >        lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
      >        down_write+0x8f/0x130 kernel/locking/rwsem.c:70
      >        inode_lock include/linux/fs.h:765 [inline]
      >        shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
      >        ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
      >        ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
      >        vfs_ioctl fs/ioctl.c:46 [inline]
      >        file_ioctl fs/ioctl.c:501 [inline]
      >        do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
      >        ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
      >        __do_sys_ioctl fs/ioctl.c:709 [inline]
      >        __se_sys_ioctl fs/ioctl.c:707 [inline]
      >        __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
      >        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      >        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      >
      > other info that might help us debug this:
      >
      > Chain exists of:
      >   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
      >
      >  Possible unsafe locking scenario:
      >
      >        CPU0                    CPU1
      >        ----                    ----
      >   lock(ashmem_mutex);
      >                                lock(&mm->mmap_sem);
      >                                lock(ashmem_mutex);
      >   lock(&sb->s_type->i_mutex_key#9);
      >
      >  *** DEADLOCK ***
      >
      > 1 lock held by syz-executor900/4483:
      >  #0: 0000000025208078 (ashmem_mutex){+.+.}, at:
      > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448
      
      Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.orgSigned-off-by: 's avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Reviewed-by: 's avatarNeilBrown <neilb@suse.com>
      Suggested-by: 's avatarNeilBrown <neilb@suse.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      946f8052
    • Pasha Tatashin's avatar
      mm: disable deferred struct page for 32-bit arches · 4cdb6f01
      Pasha Tatashin authored
      commit 889c695d upstream.
      
      Deferred struct page init is needed only on systems with large amount of
      physical memory to improve boot performance.  32-bit systems do not
      benefit from this feature.
      
      Jiri reported a problem where deferred struct pages do not work well with
      x86-32:
      
      [    0.035162] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
      [    0.035725] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
      [    0.036269] Initializing CPU#0
      [    0.036513] Initializing HighMem for node 0 (00036ffe:0007ffe0)
      [    0.038459] page:f6780000 is uninitialized and poisoned
      [    0.038460] raw: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
      [    0.039509] page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page))
      [    0.040038] ------------[ cut here ]------------
      [    0.040399] kernel BUG at include/linux/page-flags.h:293!
      [    0.040823] invalid opcode: 0000 [#1] SMP PTI
      [    0.041166] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1_pt_jiri #9
      [    0.041694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
      [    0.042496] EIP: free_highmem_page+0x64/0x80
      [    0.042839] Code: 13 46 d8 c1 e8 18 5d 83 e0 03 8d 04 c0 c1 e0 06 ff 80 ec 5f 44 d8 c3 8d b4 26 00 00 00 00 ba 08 65 28 d8 89 d8 e8 fc 71 02 00 <0f> 0b 8d 76 00 8d bc 27 00 00 00 00 ba d0 b1 26 d8 89 d8 e8 e4 71
      [    0.044338] EAX: 0000003c EBX: f6780000 ECX: 00000000 EDX: d856cbe8
      [    0.044868] ESI: 0007ffe0 EDI: d838df20 EBP: d838df00 ESP: d838defc
      [    0.045372] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210086
      [    0.045913] CR0: 80050033 CR2: 00000000 CR3: 18556000 CR4: 00040690
      [    0.046413] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [    0.046913] DR6: fffe0ff0 DR7: 00000400
      [    0.047220] Call Trace:
      [    0.047419]  add_highpages_with_active_regions+0xbd/0x10d
      [    0.047854]  set_highmem_pages_init+0x5b/0x71
      [    0.048202]  mem_init+0x2b/0x1e8
      [    0.048460]  start_kernel+0x1d2/0x425
      [    0.048757]  i386_start_kernel+0x93/0x97
      [    0.049073]  startup_32_smp+0x164/0x168
      [    0.049379] Modules linked in:
      [    0.049626] ---[ end trace 337949378db0abbb ]---
      
      We free highmem pages before their struct pages are initialized:
      
      mem_init()
       set_highmem_pages_init()
        add_highpages_with_active_regions()
         free_highmem_page()
          .. Access uninitialized struct page here..
      
      Because there is no reason to have this feature on 32-bit systems, just
      disable it.
      
      Link: http://lkml.kernel.org/r/20180831150506.31246-1-pavel.tatashin@microsoft.com
      Fixes: 2e3ca40f ("mm: relax deferred struct page requirements")
      Signed-off-by: 's avatarPavel Tatashin <pavel.tatashin@microsoft.com>
      Reported-by: 's avatarJiri Slaby <jslaby@suse.cz>
      Acked-by: 's avatarMichal Hocko <mhocko@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cdb6f01
    • KJ Tsanaktsidis's avatar
      fork: report pid exhaustion correctly · 3299a0ee
      KJ Tsanaktsidis authored
      commit f83606f5 upstream.
      
      Make the clone and fork syscalls return EAGAIN when the limit on the
      number of pids /proc/sys/kernel/pid_max is exceeded.
      
      Currently, when the pid_max limit is exceeded, the kernel will return
      ENOSPC from the fork and clone syscalls.  This is contrary to the
      documented behaviour, which explicitly calls out the pid_max case as one
      where EAGAIN should be returned.  It also leads to really confusing error
      messages in userspace programs which will complain about a lack of disk
      space when they fail to create processes/threads for this reason.
      
      This error is being returned because alloc_pid() uses the idr api to find
      a new pid; when there are none available, idr_alloc_cyclic() returns
      -ENOSPC, and this is being propagated back to userspace.
      
      This behaviour has been broken before, and was explicitly fixed in
      commit 35f71bc0 ("fork: report pid reservation failure properly"),
      so I think -EAGAIN is definitely the right thing to return in this case.
      The current behaviour change dates from commit 95846ecf ("pid:
      replace pid bitmap implementation with IDR AIP") and was I believe
      unintentional.
      
      This patch has no impact on the case where allocating a pid fails because
      the child reaper for the namespace is dead; that case will still return
      -ENOMEM.
      
      Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com
      Fixes: 95846ecf ("pid: replace pid bitmap implementation with IDR AIP")
      Signed-off-by: 's avatarKJ Tsanaktsidis <ktsanaktsidis@zendesk.com>
      Reviewed-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: 's avatarMichal Hocko <mhocko@suse.com>
      Cc: Gargi Sharma <gs051095@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3299a0ee
    • Ondrej Mosnacek's avatar
      crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2 · 30938d20
      Ondrej Mosnacek authored
      commit 24568b47 upstream.
      
      It turns out OSXSAVE needs to be checked only for AVX, not for SSE.
      Without this patch the affected modules refuse to load on CPUs with SSE2
      but without AVX support.
      
      Fixes: 877ccce7 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks")
      Cc: <stable@vger.kernel.org> # 4.18
      Reported-by: 's avatarZdenek Kaspar <zkaspar82@gmail.com>
      Signed-off-by: 's avatarOndrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30938d20
    • Vaibhav Nagarnaik's avatar
      ring-buffer: Allow for rescheduling when removing pages · d73ccd8b
      Vaibhav Nagarnaik authored
      commit 83f36555 upstream.
      
      When reducing ring buffer size, pages are removed by scheduling a work
      item on each CPU for the corresponding CPU ring buffer. After the pages
      are removed from ring buffer linked list, the pages are free()d in a
      tight loop. The loop does not give up CPU until all pages are removed.
      In a worst case behavior, when lot of pages are to be freed, it can
      cause system stall.
      
      After the pages are removed from the list, the free() can happen while
      the work is rescheduled. Call cond_resched() in the loop to prevent the
      system hangup.
      
      Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com
      
      Cc: stable@vger.kernel.org
      Fixes: 83f40318 ("ring-buffer: Make removal of ring buffer pages atomic")
      Reported-by: 's avatarJason Behmer <jbehmer@google.com>
      Signed-off-by: 's avatarVaibhav Nagarnaik <vnagarnaik@google.com>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d73ccd8b
    • Mika Westerberg's avatar
      Revert "PCI: Add ACS quirk for Intel 300 series" · 6bed4f10
      Mika Westerberg authored
      commit 50ca031b upstream.
      
      This reverts f154a718 ("PCI: Add ACS quirk for Intel 300 series").
      
      It turns out that erratum "PCH PCIe* Controller Root Port (ACSCTLR) Appear
      As Read Only" has been fixed in 300 series chipsets, even though the
      datasheet [1] claims otherwise.  To make ACS work properly on 300 series
      root ports, revert the faulty commit.
      
      [1] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/300-series-c240-series-chipset-pch-spec-update.pdf
      
      Fixes: f154a718 ("PCI: Add ACS quirk for Intel 300 series")
      Signed-off-by: 's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org	# v4.18+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bed4f10
    • Kirill Kapranov's avatar
      spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers · 6d891140
      Kirill Kapranov authored
      commit 1a4327fb upstream.
      
      On systems where some controllers get a dynamic ID assigned and some have
      a fixed number (e.g. from ACPI tables), the current implementation might
      run into an IDR collision: in case of a fixed bus number is gotten by a
      driver (but not marked busy in IDR tree) and a driver with dynamic bus
      number gets the same ID and predictably fails.
      
      Fix this by means of checking-in fixed IDsin IDR as far as dynamic ones
      at the moment of the controller registration.
      
      Fixes: 9b61e302 (spi: Pick spi bus number from Linux idr or spi alias)
      Signed-off-by: 's avatarKirill Kapranov <kirill.kapranov@compulab.co.il>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d891140
    • Boris Ostrovsky's avatar
      xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code · 1318b2c2
      Boris Ostrovsky authored
      commit 70513d58 upstream.
      
      Otherwise we may leak kernel stack for events that sample user
      registers.
      Reported-by: 's avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: 's avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: 's avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1318b2c2
    • Juergen Gross's avatar
      xen/netfront: don't bug in case of too many frags · b73a161e
      Juergen Gross authored
      commit ad4f15dc upstream.
      
      Commit 57f230ab ("xen/netfront: raise max number of slots in
      xennet_get_responses()") raised the max number of allowed slots by one.
      This seems to be problematic in some configurations with netback using
      a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS
      defined as 18 instead of nowadays 17).
      
      Instead of BUG_ON() in this case just fall back to retransmission.
      
      Fixes: 57f230ab ("xen/netfront: raise max number of slots in xennet_get_responses()")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b73a161e
    • Mario Limonciello's avatar
      platform/x86: alienware-wmi: Correct a memory leak · 5e17a1ec
      Mario Limonciello authored
      commit ff0e9f26 upstream.
      
      An ACPI buffer that was allocated was not being freed after use.
      Signed-off-by: 's avatarMario Limonciello <mario.limonciello@dell.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDarren Hart (VMware) <dvhart@infradead.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e17a1ec
    • Mario Limonciello's avatar
      platform/x86: dell-smbios-wmi: Correct a memory leak · 8879342a
      Mario Limonciello authored
      commit affab510 upstream.
      
      ACPI buffers were being allocated but never freed.
      Reported-by: 's avatarPinzhen Xu <pinzhen.xu@intel.com>
      Signed-off-by: 's avatarMario Limonciello <mario.limonciello@dell.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDarren Hart (VMware) <dvhart@infradead.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8879342a
    • Masahiro Yamada's avatar
      mtd: rawnand: denali: fix a race condition when DMA is kicked · 0639ddca
      Masahiro Yamada authored
      commit cf51e4b9 upstream.
      
      I thought the read-back of the DMA_ENABLE register was unnecessary
      (at least it is working on my boards), then deleted it in commit
      586a2c52 ("mtd: nand: denali: squash denali_enable_dma() helper
      into caller").  Sorry, I was wrong - it caused a timing issue on
      Cyclone5 SoCFPGAs.
      
      Revive the register read-back, commenting why this is necessary.
      
      Fixes: 586a2c52 ("mtd: nand: denali: squash denali_enable_dma() helper into caller")
      Cc: <stable@vger.kernel.org>
      Reported-by: 's avatarSteffen Trumtrar <s.trumtrar@pengutronix.de>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: 's avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: 's avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0639ddca
    • Boris Brezillon's avatar
      mtd: devices: m25p80: Make sure the buffer passed in op is DMA-able · f11b8aad
      Boris Brezillon authored
      commit 4a3e85f2 upstream.
      
      As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
      DMA-able, and commit 4120f8d1 ("mtd: spi-nor: Use the spi_mem_xx()
      API") failed to follow this rule as buffers passed to
      ->{read,write}_reg() are usually placed on the stack.
      
      Fix that by allocating a scratch buffer and copying the data around.
      
      Fixes: 4120f8d1 ("mtd: spi-nor: Use the spi_mem_xx() API")
      Reported-by: 's avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Tested-by: 's avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: 's avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f11b8aad
    • Takashi Sakamoto's avatar
      ALSA: oxfw: fix memory leak of private data · 1501a0f2
      Takashi Sakamoto authored
      commit 498fe23a upstream.
      
      Although private data of sound card instance is usually allocated in the
      tail of the instance, drivers in ALSA firewire stack allocate the private
      data before allocating the instance. In this case, the private data
      should be released explicitly at .private_free callback of the instance.
      
      This commit fixes memory leak following to the above design.
      
      Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1501a0f2
    • Takashi Sakamoto's avatar
      ALSA: oxfw: fix memory leak of discovered stream formats at error path · 9d07f491
      Takashi Sakamoto authored
      commit 1064bc68 upstream.
      
      After finishing discover of stream formats, ALSA OXFW driver has memory
      leak of allocated memory object at error path.
      
      This commit releases the memory object at the error path.
      
      Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d07f491
    • Takashi Sakamoto's avatar
      ALSA: oxfw: fix memory leak for model-dependent data at error path · 82567fb0
      Takashi Sakamoto authored
      commit ce925f08 upstream.
      
      After allocating model-dependent data, ALSA OXFW driver has memory leak
      of the data at error path.
      
      This commit releases the data at the error path.
      
      Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82567fb0
    • Takashi Sakamoto's avatar
      ALSA: fireworks: fix memory leak of response buffer at error path · 8e54fc89
      Takashi Sakamoto authored
      commit c3b55e2e upstream.
      
      After allocating memory object for response buffer, ALSA fireworks
      driver has leak of the memory object at error path.
      
      This commit releases the object at the error path.
      
      Fixes: 7d3c1d59('ALSA: fireworks: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e54fc89
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: fix memory leak of private data · e5301d45
      Takashi Sakamoto authored
      commit 8d28277c upstream.
      
      Although private data of sound card instance is usually allocated in the
      tail of the instance, drivers in ALSA firewire stack allocate the private
      data before allocating the instance. In this case, the private data
      should be released explicitly at .private_free callback of the instance.
      
      This commit fixes memory leak following to the above design.
      
      Fixes: b610386c ('ALSA: firewire-tascam: deleyed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5301d45
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: fix memory leak of private data · 7c57a806
      Takashi Sakamoto authored
      commit a49a83ab upstream.
      
      Although private data of sound card instance is usually allocated in the
      tail of the instance, drivers in ALSA firewire stack allocate the private
      data before allocating the instance. In this case, the private data
      should be released explicitly at .private_free callback of the instance.
      
      This commit fixes memory leak following to the above design.
      
      Fixes: 86c8dd7f ('ALSA: firewire-digi00x: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c57a806
    • Takashi Sakamoto's avatar
      ALSA: fireface: fix memory leak in ff400_switch_fetching_mode() · e9355495
      Takashi Sakamoto authored
      commit 36f3a6e0 upstream.
      
      An allocated memory forgets to be released.
      
      Fixes: 76fdb3a9 ('ALSA: fireface: add support for Fireface 400')
      Cc: <stable@vger.kernel.org> # 4.12+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9355495
    • Willy Tarreau's avatar
      ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO · cedfb9f8
      Willy Tarreau authored
      commit 49434c6c upstream.
      
      snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates
      memory using kmalloc() and partially fills it by calling
      snd_emu10k1_fx8010_info() before returning the resulting
      structure to userspace, leaving uninitialized holes. Let's
      just use kzalloc() here.
      
      BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.htmlSigned-off-by: 's avatarWilly Tarreau <w@1wt.eu>
      Cc: Jann Horn <jannh@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cedfb9f8
    • Takashi Sakamoto's avatar
      ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping · c143935a
      Takashi Sakamoto authored
      commit 493626f2 upstream.
      
      When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST',
      an address of 'payload' argument is used for streaming DMA mapping by
      'firewire_ohci' module if 'size' argument is larger than 8 byte.
      Although in this case the address should not be on kernel stack, current
      implementation of ALSA bebob driver uses data in kernel stack for a cue
      to boot M-Audio devices. This often brings unexpected result, especially
      for a case of CONFIG_VMAP_STACK=y.
      
      This commit fixes the bug.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021
      Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165
      Fixes: a2b2a779('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c143935a
    • Takashi Sakamoto's avatar
      ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path · 28114cae
      Takashi Sakamoto authored
      commit b1fbebd4 upstream.
      
      After allocating model-dependent data for M-Audio FW1814 and ProjectMix
      I/O, ALSA bebob driver has memory leak at error path.
      
      This commit releases the allocated data at the error path.
      
      Fixes: 04a2c73c('ALSA: bebob: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28114cae
    • Dmitry V. Levin's avatar
      ASoC: uapi: fix sound/skl-tplg-interface.h userspace compilation errors · 30100a47
      Dmitry V. Levin authored
      commit fb504caa upstream.
      
      Include <linux/types.h> and consistently use types it provides
      to fix the following sound/skl-tplg-interface.h userspace compilation errors:
      
      /usr/include/sound/skl-tplg-interface.h:146:2: error: unknown type name 'u32'
        u32 set_params:2;
      /usr/include/sound/skl-tplg-interface.h:147:2: error: unknown type name 'u32'
        u32 rsvd:30;
      /usr/include/sound/skl-tplg-interface.h:148:2: error: unknown type name 'u32'
        u32 param_id;
      /usr/include/sound/skl-tplg-interface.h:149:2: error: unknown type name 'u32'
        u32 max;
      /usr/include/sound/skl-tplg-interface.h:166:2: error: unknown type name 'u16'
        u16 module_id;
      /usr/include/sound/skl-tplg-interface.h:167:2: error: unknown type name 'u16'
        u16 instance_id;
      /usr/include/sound/skl-tplg-interface.h:171:2: error: unknown type name 'u32'
        u32 channels;
      /usr/include/sound/skl-tplg-interface.h:172:2: error: unknown type name 'u32'
        u32 freq;
      /usr/include/sound/skl-tplg-interface.h:173:2: error: unknown type name 'u32'
        u32 bit_depth;
      /usr/include/sound/skl-tplg-interface.h:174:2: error: unknown type name 'u32'
        u32 valid_bit_depth;
      /usr/include/sound/skl-tplg-interface.h:175:2: error: unknown type name 'u32'
        u32 ch_cfg;
      /usr/include/sound/skl-tplg-interface.h:176:2: error: unknown type name 'u32'
        u32 interleaving_style;
      /usr/include/sound/skl-tplg-interface.h:177:2: error: unknown type name 'u32'
        u32 sample_type;
      /usr/include/sound/skl-tplg-interface.h:178:2: error: unknown type name 'u32'
        u32 ch_map;
      /usr/include/sound/skl-tplg-interface.h:182:2: error: unknown type name 'u32'
        u32 set_params:2;
      /usr/include/sound/skl-tplg-interface.h:183:2: error: unknown type name 'u32'
        u32 rsvd:30;
      /usr/include/sound/skl-tplg-interface.h:184:2: error: unknown type name 'u32'
        u32 param_id;
      /usr/include/sound/skl-tplg-interface.h:185:2: error: unknown type name 'u32'
        u32 caps_size;
      /usr/include/sound/skl-tplg-interface.h:186:2: error: unknown type name 'u32'
        u32 caps[HDA_SST_CFG_MAX];
      /usr/include/sound/skl-tplg-interface.h:190:2: error: unknown type name 'u8'
        u8 pipe_id;
      /usr/include/sound/skl-tplg-interface.h:191:2: error: unknown type name 'u8'
        u8 pipe_priority;
      /usr/include/sound/skl-tplg-interface.h:192:2: error: unknown type name 'u16'
        u16 conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:193:2: error: unknown type name 'u16'
        u16 rsvd:4;
      /usr/include/sound/skl-tplg-interface.h:194:2: error: unknown type name 'u16'
        u16 memory_pages:8;
      /usr/include/sound/skl-tplg-interface.h:200:2: error: unknown type name 'u16'
        u16 module_id;
      /usr/include/sound/skl-tplg-interface.h:201:2: error: unknown type name 'u16'
        u16 instance_id;
      /usr/include/sound/skl-tplg-interface.h:202:2: error: unknown type name 'u32'
        u32 max_mcps;
      /usr/include/sound/skl-tplg-interface.h:203:2: error: unknown type name 'u32'
        u32 mem_pages;
      /usr/include/sound/skl-tplg-interface.h:204:2: error: unknown type name 'u32'
        u32 obs;
      /usr/include/sound/skl-tplg-interface.h:205:2: error: unknown type name 'u32'
        u32 ibs;
      /usr/include/sound/skl-tplg-interface.h:206:2: error: unknown type name 'u32'
        u32 vbus_id;
      /usr/include/sound/skl-tplg-interface.h:208:2: error: unknown type name 'u32'
        u32 max_in_queue:8;
      /usr/include/sound/skl-tplg-interface.h:209:2: error: unknown type name 'u32'
        u32 max_out_queue:8;
      /usr/include/sound/skl-tplg-interface.h:210:2: error: unknown type name 'u32'
        u32 time_slot:8;
      /usr/include/sound/skl-tplg-interface.h:211:2: error: unknown type name 'u32'
        u32 core_id:4;
      /usr/include/sound/skl-tplg-interface.h:212:2: error: unknown type name 'u32'
        u32 rsvd1:4;
      /usr/include/sound/skl-tplg-interface.h:214:2: error: unknown type name 'u32'
        u32 module_type:8;
      /usr/include/sound/skl-tplg-interface.h:215:2: error: unknown type name 'u32'
        u32 conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:216:2: error: unknown type name 'u32'
        u32 dev_type:4;
      /usr/include/sound/skl-tplg-interface.h:217:2: error: unknown type name 'u32'
        u32 hw_conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:218:2: error: unknown type name 'u32'
        u32 rsvd2:12;
      /usr/include/sound/skl-tplg-interface.h:220:2: error: unknown type name 'u32'
        u32 params_fixup:8;
      /usr/include/sound/skl-tplg-interface.h:221:2: error: unknown type name 'u32'
        u32 converter:8;
      /usr/include/sound/skl-tplg-interface.h:222:2: error: unknown type name 'u32'
        u32 input_pin_type:1;
      /usr/include/sound/skl-tplg-interface.h:223:2: error: unknown type name 'u32'
        u32 output_pin_type:1;
      /usr/include/sound/skl-tplg-interface.h:224:2: error: unknown type name 'u32'
        u32 is_dynamic_in_pin:1;
      /usr/include/sound/skl-tplg-interface.h:225:2: error: unknown type name 'u32'
        u32 is_dynamic_out_pin:1;
      /usr/include/sound/skl-tplg-interface.h:226:2: error: unknown type name 'u32'
        u32 is_loadable:1;
      /usr/include/sound/skl-tplg-interface.h:227:2: error: unknown type name 'u32'
        u32 rsvd3:11;
      
      Fixes: 0c24fdc0 ("ASoC: topology: Move skl-tplg-interface.h to uapi")
      Signed-off-by: 's avatarDmitry V. Levin <ldv@altlinux.org>
      Reviewed-by: 's avatarGuenter Roeck <groeck@chromium.org>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # v4.18
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30100a47
    • Jiada Wang's avatar
      ASoC: rsnd: fixup not to call clk_get/set under non-atomic · 341ff629
      Jiada Wang authored
      commit 4d230d12 upstream.
      
      Clocking operations clk_get/set_rate, are non-atomic,
      they shouldn't be called in soc_pcm_trigger() which is atomic.
      
      Following issue was found due to execution of clk_get_rate() causes
      sleep in soc_pcm_trigger(), which shouldn't be blocked.
      
      We can reproduce this issue by following
      	> enable CONFIG_DEBUG_ATOMIC_SLEEP=y
      	> compile, and boot
      	> mount -t debugfs none /sys/kernel/debug
      	> while true; do cat /sys/kernel/debug/clk/clk_summary > /dev/null; done &
      	> while true; do aplay xxx; done
      
      This patch adds support to .prepare callback, and moves non-atomic
      clocking operations to it. As .prepare is non-atomic, it is always
      called before trigger_start/trigger_stop.
      
      	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      	in_atomic(): 1, irqs_disabled(): 128, pid: 2242, name: aplay
      	INFO: lockdep is turned off.
      	irq event stamp: 5964
      	hardirqs last enabled at (5963): [<ffff200008e59e40>] mutex_lock_nested+0x6e8/0x6f0
      	hardirqs last disabled at (5964): [<ffff200008e623f0>] _raw_spin_lock_irqsave+0x24/0x68
      	softirqs last enabled at (5502): [<ffff200008081838>] __do_softirq+0x560/0x10c0
      	softirqs last disabled at (5495): [<ffff2000080c2e78>] irq_exit+0x160/0x25c
      	Preemption disabled at:[ 62.904063] [<ffff200008be4d48>] snd_pcm_stream_lock+0xb4/0xc0
      	CPU: 2 PID: 2242 Comm: aplay Tainted: G B C 4.9.54+ #186
      	Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
      	Call trace:
      	[<ffff20000808fe48>] dump_backtrace+0x0/0x37c
      	[<ffff2000080901d8>] show_stack+0x14/0x1c
      	[<ffff2000086f4458>] dump_stack+0xfc/0x154
      	[<ffff2000081134a0>] ___might_sleep+0x57c/0x58c
      	[<ffff2000081136b8>] __might_sleep+0x208/0x21c
      	[<ffff200008e5980c>] mutex_lock_nested+0xb4/0x6f0
      	[<ffff2000087cac74>] clk_prepare_lock+0xb0/0x184
      	[<ffff2000087cb094>] clk_core_get_rate+0x14/0x54
      	[<ffff2000087cb0f4>] clk_get_rate+0x20/0x34
      	[<ffff20000113aa00>] rsnd_adg_ssi_clk_try_start+0x158/0x4f8 [snd_soc_rcar]
      	[<ffff20000113da00>] rsnd_ssi_init+0x668/0x7a0 [snd_soc_rcar]
      	[<ffff200001133ff4>] rsnd_soc_dai_trigger+0x4bc/0xcf8 [snd_soc_rcar]
      	[<ffff200008c1af24>] soc_pcm_trigger+0x2a4/0x2d4
      
      Fixes: e7d850dd ("ASoC: rsnd: use mod base common method on SSI-parent")
      Signed-off-by: 's avatarJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: 's avatarTimo Wischer <twischer@de.adit-jv.com>
      [Kuninori: tidyup for upstream]
      Signed-off-by: 's avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Tested-by: 's avatarHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      341ff629
    • Andrew F. Davis's avatar
      ASoC: tas6424: Save last fault register even when clear · 9e6a69b0
      Andrew F. Davis authored
      commit d40e3e9e upstream.
      
      When there is no fault bit set in a fault register we skip the fault
      reporting section for that register. This also skips over saving that
      registers value. We save the value so we will not double report an
      error, but if an error clears then returns we will also not report it
      as we did not save the all cleared register value. Fix this by saving
      the fault register value in the all clear path.
      Signed-off-by: 's avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e6a69b0
    • Sébastien Szymanski's avatar
      ASoC: cs4265: fix MMTLR Data switch control · df231dbe
      Sébastien Szymanski authored
      commit 90a3b7f8 upstream.
      
      The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0
      and not at address 0x0 bit 1. Fix this.
      Signed-off-by: 's avatarSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df231dbe
    • Marcel Ziswiler's avatar
      ASoC: wm9712: fix replace codec to component · 401e975e
      Marcel Ziswiler authored
      commit 5e4cfada upstream.
      
      Since commit 143b4484 ("ASoC: wm9712: replace codec to component")
      "wm9712-codec" got renamed to "wm9712-component", however, this change
      never got propagated down to the actual board/platform drivers. E.g. on
      Colibri T20 this lead to the following spew upon boot with sound/touch
      being broken:
      
      [    2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [   14.970443] ALSA device list:
      [   14.996628]   No soundcards found.
      
      This commit finally fixes this again.
      Signed-off-by: 's avatarMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Acked-by: 's avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      401e975e
    • Suren Baghdasaryan's avatar
      NFC: Fix the number of pipes · 58be75ff
      Suren Baghdasaryan authored
      commit e285d5bf upstream.
      
      According to ETSI TS 102 622 specification chapter 4.4 pipe identifier
      is 7 bits long which allows for 128 unique pipe IDs. Because
      NFC_HCI_MAX_PIPES is used as the number of pipes supported and not
      as the max pipe ID, its value should be 128 instead of 127.
      
      nfc_hci_recv_from_llc extracts pipe ID from packet header using
      NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127.
      Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With
      pipes array having only 127 elements and pipe ID of 127 the OOB memory
      access will result.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Allen Pais <allen.pais@oracle.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Suggested-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: 's avatarSuren Baghdasaryan <surenb@google.com>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58be75ff
    • Suren Baghdasaryan's avatar
      NFC: Fix possible memory corruption when handling SHDLC I-Frame commands · 0ad778ee
      Suren Baghdasaryan authored
      commit 674d9de0 upstream.
      
      When handling SHDLC I-Frame commands "pipe" field used for indexing
      into an array should be checked before usage. If left unchecked it
      might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
      
      Malformed NFC HCI frames could be injected by a malicious NFC device
      communicating with the device being attacked (remote attack vector),
      or even by an attacker with physical access to the I2C bus such that
      they could influence the data transfers on that bus (local attack vector).
      skb->data is controlled by the attacker and has only been sanitized in
      the most trivial ways (CRC check), therefore we can consider the
      create_info struct and all of its members to tainted. 'create_info->pipe'
      with max value of 255 (uint8) is used to take an offset of the
      hdev->pipes array of 127 elements which can lead to OOB write.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Allen Pais <allen.pais@oracle.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Suggested-by: 's avatarKevin Deus <kdeus@google.com>
      Signed-off-by: 's avatarSuren Baghdasaryan <surenb@google.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ad778ee
    • Roopa Prabhu's avatar
      net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags · 18b8a9c5
      Roopa Prabhu authored
      [ Upstream commit 56a49d70 ]
      
      This fix addresses https://bugzilla.kernel.org/show_bug.cgi?id=201071
      
      Commit 5025f7f7 wrongly relied on __dev_change_flags to notify users of
      dev flag changes in the case when dev->rtnl_link_state = RTNL_LINK_INITIALIZED.
      Fix it by indicating flag changes explicitly to __dev_notify_flags.
      
      Fixes: 5025f7f7 ("rtnetlink: add rtnl_link_state check in rtnl_configure_link")
      Reported-By: 's avatarLiam mcbirnie <liam.mcbirnie@boeing.com>
      Signed-off-by: 's avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18b8a9c5
    • Antoine Tenart's avatar
      net: mvpp2: let phylink manage the carrier state · 1b469799
      Antoine Tenart authored
      [ Upstream commit 41948ccb ]
      
      Net drivers using phylink shouldn't mess with the link carrier
      themselves and should let phylink manage it. The mvpp2 driver wasn't
      following this best practice as the mac_config() function made calls to
      change the link carrier state. This led to wrongly reported carrier link
      state which then triggered other issues. This patch fixes this
      behaviour.
      
      But the PPv2 driver relied on this misbehaviour in two cases: for fixed
      links and when not using phylink (ACPI mode). The later was fixed by
      adding an explicit call to link_up(), which when the ACPI mode will use
      phylink should be removed.
      
      The fixed link case was relying on the mac_config() function to set the
      link up, as we found an issue in phylink_start() which assumes the
      carrier is off. If not, the link_up() function is never called. To fix
      this, a call to netif_carrier_off() is added just before phylink_start()
      so that we do not introduce a regression in the driver.
      
      Fixes: 4bb04326 ("net: mvpp2: phylink support")
      Reported-by: 's avatarRussell King <linux@armlinux.org.uk>
      Signed-off-by: 's avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b469799
    • Peter Oskolkov's avatar
      net/ipv6: do not copy dst flags on rt init · 001e4e55
      Peter Oskolkov authored
      [ Upstream commit 30bfd930 ]
      
      DST_NOCOUNT in dst_entry::flags tracks whether the entry counts
      toward route cache size (net->ipv6.sysctl.ip6_rt_max_size).
      
      If the flag is NOT set, dst_ops::pcpuc_entries counter is incremented
      in dist_init() and decremented in dst_destroy().
      
      This flag is tied to allocation/deallocation of dst_entry and
      should not be copied from another dst/route. Otherwise it can happen
      that dst_ops::pcpuc_entries counter grows until no new routes can
      be allocated because the counter reached ip6_rt_max_size due to
      DST_NOCOUNT not set and thus no counter decrements on gc-ed routes.
      
      Fixes: 3b6761d1 ("net/ipv6: Move dst flags to booleans in fib entries")
      Cc: David Ahern <dsahern@gmail.com>
      Acked-by: 's avatarWei Wang <weiwan@google.com>
      Signed-off-by: 's avatarPeter Oskolkov <posk@google.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      001e4e55
    • Xin Long's avatar
      ipv6: use rt6_info members when dst is set in rt6_fill_node · 1328a5a4
      Xin Long authored
      [ Upstream commit 22d0bd82 ]
      
      In inet6_rtm_getroute, since Commit 93531c67 ("net/ipv6: separate
      handling of FIB entries from dst based routes"), it has used rt->from
      to dump route info instead of rt.
      
      However for some route like cache, some of its information like flags
      or gateway is not the same as that of the 'from' one. It caused 'ip
      route get' to dump the wrong route information.
      
      In Jianlin's testing, the output information even lost the expiration
      time for a pmtu route cache due to the wrong fib6_flags.
      
      So change to use rt6_info members for dst addr, src addr, flags and
      gateway when it tries to dump a route entry without fibmatch set.
      
      v1->v2:
        - not use rt6i_prefsrc.
        - also fix the gw dump issue.
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: 's avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1328a5a4
    • Michael Chan's avatar
      bnxt_en: Fix VF mac address regression. · b5fc7f30
      Michael Chan authored
      [ Upstream commit 28ea334b ]
      
      The recent commit to always forward the VF MAC address to the PF for
      approval may not work if the PF driver or the firmware is older.  This
      will cause the VF driver to fail during probe:
      
        bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): hwrm req_type 0xf seq id 0x5 error 0xffff
        bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): VF MAC address 00:00:17:02:05:d0 not approved by the PF
        bnxt_en 0000:00:03.0: Unable to initialize mac address.
        bnxt_en: probe of 0000:00:03.0 failed with error -99
      
      We fix it by treating the error as fatal only if the VF MAC address is
      locally generated by the VF.
      
      Fixes: 707e7e96 ("bnxt_en: Always forward VF MAC address to the PF.")
      Reported-by: 's avatarSeth Forshee <seth.forshee@canonical.com>
      Reported-by: 's avatarSiwei Liu <loseweigh@gmail.com>
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5fc7f30
    • Daniel Borkmann's avatar
      tls: fix currently broken MSG_PEEK behavior · 8ac22b32
      Daniel Borkmann authored
      [ Upstream commit 50c6b58a ]
      
      In kTLS MSG_PEEK behavior is currently failing, strace example:
      
        [pid  2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
        [pid  2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
        [pid  2430] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2430] listen(4, 10)               = 0
        [pid  2430] getsockname(4, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
        [pid  2430] connect(3, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2430] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2430] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2430] accept(4, {sa_family=AF_INET, sin_port=htons(49636), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
        [pid  2430] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2430] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2430] close(4)                    = 0
        [pid  2430] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
        [pid  2430] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
        [pid  2430] recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
      
      As can be seen from strace, there are two TLS records sent,
      i) 'test_read_peek' and ii) '_mult_recs\0' where we end up
      peeking 'test_read_peektest_read_peektest'. This is clearly
      wrong, and what happens is that given peek cannot call into
      tls_sw_advance_skb() to unpause strparser and proceed with
      the next skb, we end up looping over the current one, copying
      the 'test_read_peek' over and over into the user provided
      buffer.
      
      Here, we can only peek into the currently held skb (current,
      full TLS record) as otherwise we would end up having to hold
      all the original skb(s) (depending on the peek depth) in a
      separate queue when unpausing strparser to process next
      records, minimally intrusive is to return only up to the
      current record's size (which likely was what c46234eb
      ("tls: RX path for ktls") originally intended as well). Thus,
      after patch we properly peek the first record:
      
        [pid  2046] wait4(2075,  <unfinished ...>
        [pid  2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
        [pid  2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
        [pid  2075] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2075] listen(4, 10)               = 0
        [pid  2075] getsockname(4, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
        [pid  2075] connect(3, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2075] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2075] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2075] accept(4, {sa_family=AF_INET, sin_port=htons(45732), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
        [pid  2075] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2075] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2075] close(4)                    = 0
        [pid  2075] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
        [pid  2075] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
        [pid  2075] recvfrom(5, "test_read_peek", 64, MSG_PEEK, NULL, NULL) = 14
      
      Fixes: c46234eb ("tls: RX path for ktls")
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ac22b32
    • Johannes Berg's avatar
      socket: fix struct ifreq size in compat ioctl · 17eef150
      Johannes Berg authored
      [ Upstream commit 1cebf8f1 ]
      
      As reported by Reobert O'Callahan, since Viro's commit to kill
      dev_ifsioc() we attempt to copy too much data in compat mode,
      which may lead to EFAULT when the 32-bit version of struct ifreq
      sits at/near the end of a page boundary, and the next page isn't
      mapped.
      
      Fix this by passing the approprate compat/non-compat size to copy
      and using that, as before the dev_ifsioc() removal. This works
      because only the embedded "struct ifmap" has different size, and
      this is only used in SIOCGIFMAP/SIOCSIFMAP which has a different
      handler. All other parts of the union are naturally compatible.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199469.
      
      Fixes: bf440573 ("kill dev_ifsioc()")
      Reported-by: 's avatarRobert O'Callahan <robert@ocallahan.org>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17eef150
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Fix ATU Miss Violation · 263baf63
      Andrew Lunn authored
      [ Upstream commit ddca24df ]
      
      Fix a cut/paste error and a typo which results in ATU miss violations
      not being reported.
      
      Fixes: 0977644c ("net: dsa: mv88e6xxx: Decode ATU problem interrupt")
      Signed-off-by: 's avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      263baf63
    • Stephen Hemminger's avatar
      hv_netvsc: fix schedule in RCU context · 4188aa04
      Stephen Hemminger authored
      [ Upstream commit 018349d7 ]
      
      When netvsc device is removed it can call reschedule in RCU context.
      This happens because canceling the subchannel setup work could (in theory)
      cause a reschedule when manipulating the timer.
      
      To reproduce, run with lockdep enabled kernel and unbind
      a network device from hv_netvsc (via sysfs).
      
      [  160.682011] WARNING: suspicious RCU usage
      [  160.707466] 4.19.0-rc3-uio+ #2 Not tainted
      [  160.709937] -----------------------------
      [  160.712352] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
      [  160.723691]
      [  160.723691] other info that might help us debug this:
      [  160.723691]
      [  160.730955]
      [  160.730955] rcu_scheduler_active = 2, debug_locks = 1
      [  160.762813] 5 locks held by rebind-eth.sh/1812:
      [  160.766851]  #0: 000000008befa37a (sb_writers#6){.+.+}, at: vfs_write+0x184/0x1b0
      [  160.773416]  #1: 00000000b097f236 (&of->mutex){+.+.}, at: kernfs_fop_write+0xe2/0x1a0
      [  160.783766]  #2: 0000000041ee6889 (kn->count#3){++++}, at: kernfs_fop_write+0xeb/0x1a0
      [  160.787465]  #3: 0000000056d92a74 (&dev->mutex){....}, at: device_release_driver_internal+0x39/0x250
      [  160.816987]  #4: 0000000030f6031e (rcu_read_lock){....}, at: netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.828629]
      [  160.828629] stack backtrace:
      [  160.831966] CPU: 1 PID: 1812 Comm: rebind-eth.sh Not tainted 4.19.0-rc3-uio+ #2
      [  160.832952] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [  160.832952] Call Trace:
      [  160.832952]  dump_stack+0x85/0xcb
      [  160.832952]  ___might_sleep+0x1a3/0x240
      [  160.832952]  __flush_work+0x57/0x2e0
      [  160.832952]  ? __mutex_lock+0x83/0x990
      [  160.832952]  ? __kernfs_remove+0x24f/0x2e0
      [  160.832952]  ? __kernfs_remove+0x1b2/0x2e0
      [  160.832952]  ? mark_held_locks+0x50/0x80
      [  160.832952]  ? get_work_pool+0x90/0x90
      [  160.832952]  __cancel_work_timer+0x13c/0x1e0
      [  160.832952]  ? netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.832952]  ? __lock_is_held+0x55/0x90
      [  160.832952]  netvsc_remove+0x9a/0x250 [hv_netvsc]
      [  160.832952]  vmbus_remove+0x26/0x30
      [  160.832952]  device_release_driver_internal+0x18a/0x250
      [  160.832952]  unbind_store+0xb4/0x180
      [  160.832952]  kernfs_fop_write+0x113/0x1a0
      [  160.832952]  __vfs_write+0x36/0x1a0
      [  160.832952]  ? rcu_read_lock_sched_held+0x6b/0x80
      [  160.832952]  ? rcu_sync_lockdep_assert+0x2e/0x60
      [  160.832952]  ? __sb_start_write+0x141/0x1a0
      [  160.832952]  ? vfs_write+0x184/0x1b0
      [  160.832952]  vfs_write+0xbe/0x1b0
      [  160.832952]  ksys_write+0x55/0xc0
      [  160.832952]  do_syscall_64+0x60/0x1b0
      [  160.832952]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  160.832952] RIP: 0033:0x7fe48f4c8154
      
      Resolve this by getting RTNL earlier. This is safe because the subchannel
      work queue does trylock on RTNL and will detect the race.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Signed-off-by: 's avatarStephen Hemminger <sthemmin@microsoft.com>
      Reviewed-by: 's avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4188aa04
    • Davide Caratti's avatar
      net/sched: act_sample: fix NULL dereference in the data path · 9f248964
      Davide Caratti authored
      [ Upstream commit 34043d25 ]
      
      Matteo reported the following splat, testing the datapath of TC 'sample':
      
       BUG: KASAN: null-ptr-deref in tcf_sample_act+0xc4/0x310
       Read of size 8 at addr 0000000000000000 by task nc/433
      
       CPU: 0 PID: 433 Comm: nc Not tainted 4.19.0-rc3-kvm #17
       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
       Call Trace:
        kasan_report.cold.6+0x6c/0x2fa
        tcf_sample_act+0xc4/0x310
        ? dev_hard_start_xmit+0x117/0x180
        tcf_action_exec+0xa3/0x160
        tcf_classify+0xdd/0x1d0
        htb_enqueue+0x18e/0x6b0
        ? deref_stack_reg+0x7a/0xb0
        ? htb_delete+0x4b0/0x4b0
        ? unwind_next_frame+0x819/0x8f0
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        __dev_queue_xmit+0x722/0xca0
        ? unwind_get_return_address_ptr+0x50/0x50
        ? netdev_pick_tx+0xe0/0xe0
        ? save_stack+0x8c/0xb0
        ? kasan_kmalloc+0xbe/0xd0
        ? __kmalloc_track_caller+0xe4/0x1c0
        ? __kmalloc_reserve.isra.45+0x24/0x70
        ? __alloc_skb+0xdd/0x2e0
        ? sk_stream_alloc_skb+0x91/0x3b0
        ? tcp_sendmsg_locked+0x71b/0x15a0
        ? tcp_sendmsg+0x22/0x40
        ? __sys_sendto+0x1b0/0x250
        ? __x64_sys_sendto+0x6f/0x80
        ? do_syscall_64+0x5d/0x150
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        ? __sys_sendto+0x1b0/0x250
        ? __x64_sys_sendto+0x6f/0x80
        ? do_syscall_64+0x5d/0x150
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        ip_finish_output2+0x495/0x590
        ? ip_copy_metadata+0x2e0/0x2e0
        ? skb_gso_validate_network_len+0x6f/0x110
        ? ip_finish_output+0x174/0x280
        __tcp_transmit_skb+0xb17/0x12b0
        ? __tcp_select_window+0x380/0x380
        tcp_write_xmit+0x913/0x1de0
        ? __sk_mem_schedule+0x50/0x80
        tcp_sendmsg_locked+0x49d/0x15a0
        ? tcp_rcv_established+0x8da/0xa30
        ? tcp_set_state+0x220/0x220
        ? clear_user+0x1f/0x50
        ? iov_iter_zero+0x1ae/0x590
        ? __fget_light+0xa0/0xe0
        tcp_sendmsg+0x22/0x40
        __sys_sendto+0x1b0/0x250
        ? __ia32_sys_getpeername+0x40/0x40
        ? _copy_to_user+0x58/0x70
        ? poll_select_copy_remaining+0x176/0x200
        ? __pollwait+0x1c0/0x1c0
        ? ktime_get_ts64+0x11f/0x140
        ? kern_select+0x108/0x150
        ? core_sys_select+0x360/0x360
        ? vfs_read+0x127/0x150
        ? kernel_write+0x90/0x90
        __x64_sys_sendto+0x6f/0x80
        do_syscall_64+0x5d/0x150
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7fefef2b129d
       Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 51 37 0c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41
       RSP: 002b:00007fff2f5350c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000056118d60c120 RCX: 00007fefef2b129d
       RDX: 0000000000002000 RSI: 000056118d629320 RDI: 0000000000000003
       RBP: 000056118d530370 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000002000
       R13: 000056118d5c2a10 R14: 000056118d5c2a10 R15: 000056118d5303b8
      
      tcf_sample_act() tried to update its per-cpu stats, but tcf_sample_init()
      forgot to allocate them, because tcf_idr_create() was called with a wrong
      value of 'cpustats'. Setting it to true proved to fix the reported crash.
      Reported-by: 's avatarMatteo Croce <mcroce@redhat.com>
      Fixes: 65a206c0 ("net/sched: Change act_api and act_xxx modules to use IDR")
      Fixes: 5c5670fa ("net/sched: Introduce sample tc action")
      Tested-by: 's avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: 's avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f248964