1. 22 Jun, 2019 37 commits
    • Yingjoe Chen's avatar
      i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr · 7bea5618
      Yingjoe Chen authored
      [ Upstream commit a0692f0e ]
      
      If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
      will not be freed. Pump index up so it will be freed.
      
      Fixes: 838bfa60
      
       ("i2c-dev: Add support for I2C_M_RECV_LEN")
      Signed-off-by: default avatarYingjoe Chen <yingjoe.chen@mediatek.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7bea5618
    • Dmitry Bogdanov's avatar
      net: aquantia: fix LRO with FCS error · 197501af
      Dmitry Bogdanov authored
      [ Upstream commit eaeb3b74 ]
      
      Driver stops producing skbs on ring if a packet with FCS error
      was coalesced into LRO session. Ring gets hang forever.
      
      Thats a logical error in driver processing descriptors:
      When rx_stat indicates MAC Error, next pointer and eop flags
      are not filled. This confuses driver so it waits for descriptor 0
      to be filled by HW.
      
      Solution is fill next pointer and eop flag even for packets with FCS error.
      
      Fixes: bab6de8f
      
       ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      197501af
    • Igor Russkikh's avatar
      net: aquantia: tx clean budget logic error · 388534d4
      Igor Russkikh authored
      [ Upstream commit 31bafc49 ]
      
      In case no other traffic happening on the ring, full tx cleanup
      may not be completed. That may cause socket buffer to overflow
      and tx traffic to stuck until next activity on the ring happens.
      
      This is due to logic error in budget variable decrementor.
      Variable is compared with zero, and then post decremented,
      causing it to become MAX_INT. Solution is remove decrementor
      from the `for` statement and rewrite it in a clear way.
      
      Fixes: b647d398
      
       ("net: aquantia: Add tx clean budget and valid budget handling logic")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      388534d4
    • Lucas Stach's avatar
      drm/etnaviv: lock MMU while dumping core · b7ca3f33
      Lucas Stach authored
      [ Upstream commit 1396500d ]
      
      The devcoredump needs to operate on a stable state of the MMU while
      it is writing the MMU state to the coredump. The missing lock
      allowed both the userspace submit, as well as the GPU job finish
      paths to mutate the MMU state while a coredump is under way.
      
      Fixes: a8c21a54
      
       (drm/etnaviv: add initial etnaviv DRM driver)
      Reported-by: default avatarDavid Jander <david@protonic.nl>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Tested-by: default avatarDavid Jander <david@protonic.nl>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7ca3f33
    • Rafael J. Wysocki's avatar
      ACPI/PCI: PM: Add missing wakeup.flags.valid checks · ee61fb4d
      Rafael J. Wysocki authored
      [ Upstream commit 9a51c6b1
      
       ]
      
      Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the
      current ACPI wakeup configuration of the device matches what is
      expected as far as system wakeup from sleep states is concerned, as
      reflected by the device_may_wakeup() return value for the device.
      
      However, they only should do that if wakeup.flags.valid is set for
      the device's ACPI companion, because otherwise the wakeup.prepare_count
      value for it is meaningless.
      
      Add the missing wakeup.flags.valid checks to these functions.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee61fb4d
    • Kees Cook's avatar
      net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE() · bc19b50b
      Kees Cook authored
      [ Upstream commit 3e66b7cc ]
      
      Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():
      
      drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:90:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:85:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      
      This drops the one further from the table definition to match the common
      use of MODULE_DEVICE_TABLE().
      
      Fixes: 07563c71
      
       ("EISA bus MODALIAS attributes support")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bc19b50b
    • Biao Huang's avatar
      net: stmmac: update rx tail pointer register to fix rx dma hang issue. · 9a3208b6
      Biao Huang authored
      [ Upstream commit 4523a561 ]
      
      Currently we will not update the receive descriptor tail pointer in
      stmmac_rx_refill. Rx dma will think no available descriptors and stop
      once received packets exceed DMA_RX_SIZE, so that the rx only test will fail.
      
      Update the receive tail pointer in stmmac_rx_refill to add more descriptors
      to the rx channel, so packets can be received continually
      
      Fixes: 54139cf3
      
       ("net: stmmac: adding multiple buffers for rx")
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a3208b6
    • Randy Dunlap's avatar
      gpio: fix gpio-adp5588 build errors · 3fbcef33
      Randy Dunlap authored
      [ Upstream commit e9646f0f ]
      
      The gpio-adp5588 driver uses interfaces that are provided by
      GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry.
      
      Fixes these build errors:
      
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’:
      ../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’
                  dev->gpio_chip.irq.domain, gpio));
                                ^
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’:
      ../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration]
        ret = gpiochip_irqchip_add_nested(&dev->gpio_chip,
        ^
      ../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration]
        gpiochip_set_nested_irqchip(&dev->gpio_chip,
        ^
      
      Fixes: 459773ae
      
       ("gpio: adp5588-gpio: support interrupt controller")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: linux-gpio@vger.kernel.org
      Reviewed-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Acked-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3fbcef33
    • Peter Zijlstra's avatar
      perf/ring-buffer: Always use {READ,WRITE}_ONCE() for rb->user_page data · 991ea848
      Peter Zijlstra authored
      [ Upstream commit 4d839dd9
      
       ]
      
      We must use {READ,WRITE}_ONCE() on rb->user_page data such that
      concurrent usage will see whole values. A few key sites were missing
      this.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: 7b732a75 ("perf_counter: new output ABI - part 1")
      Link: http://lkml.kernel.org/r/20190517115418.394192145@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      991ea848
    • Peter Zijlstra's avatar
      perf/ring_buffer: Add ordering to rb->nest increment · c133c9db
      Peter Zijlstra authored
      [ Upstream commit 3f9fbe9b
      
       ]
      
      Similar to how decrementing rb->next too early can cause data_head to
      (temporarily) be observed to go backward, so too can this happen when
      we increment too late.
      
      This barrier() ensures the rb->head load happens after the increment,
      both the one in the 'goto again' path, as the one from
      perf_output_get_handle() -- albeit very unlikely to matter for the
      latter.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.309516009@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c133c9db
    • Yabin Cui's avatar
      perf/ring_buffer: Fix exposing a temporarily decreased data_head · cca19ab2
      Yabin Cui authored
      [ Upstream commit 1b038c6e
      
       ]
      
      In perf_output_put_handle(), an IRQ/NMI can happen in below location and
      write records to the same ring buffer:
      
      	...
      	local_dec_and_test(&rb->nest)
      	...                          <-- an IRQ/NMI can happen here
      	rb->user_page->data_head = head;
      	...
      
      In this case, a value A is written to data_head in the IRQ, then a value
      B is written to data_head after the IRQ. And A > B. As a result,
      data_head is temporarily decreased from A to B. And a reader may see
      data_head < data_tail if it read the buffer frequently enough, which
      creates unexpected behaviors.
      
      This can be fixed by moving dec(&rb->nest) to after updating data_head,
      which prevents the IRQ/NMI above from updating data_head.
      
      [ Split up by peterz. ]
      Signed-off-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: mark.rutland@arm.com
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.224478157@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cca19ab2
    • Frank van der Linden's avatar
      x86/CPU/AMD: Don't force the CPB cap when running under a hypervisor · a35e7822
      Frank van der Linden authored
      [ Upstream commit 2ac44ab6
      
       ]
      
      For F17h AMD CPUs, the CPB capability ('Core Performance Boost') is forcibly set,
      because some versions of that chip incorrectly report that they do not have it.
      
      However, a hypervisor may filter out the CPB capability, for good
      reasons. For example, KVM currently does not emulate setting the CPB
      bit in MSR_K7_HWCR, and unchecked MSR access errors will be thrown
      when trying to set it as a guest:
      
      	unchecked MSR access error: WRMSR to 0xc0010015 (tried to write 0x0000000001000011) at rIP: 0xffffffff890638f4 (native_write_msr+0x4/0x20)
      
      	Call Trace:
      	boost_set_msr+0x50/0x80 [acpi_cpufreq]
      	cpuhp_invoke_callback+0x86/0x560
      	sort_range+0x20/0x20
      	cpuhp_thread_fun+0xb0/0x110
      	smpboot_thread_fn+0xef/0x160
      	kthread+0x113/0x130
      	kthread_create_worker_on_cpu+0x70/0x70
      	ret_from_fork+0x35/0x40
      
      To avoid this issue, don't forcibly set the CPB capability for a CPU
      when running under a hypervisor.
      Signed-off-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: jiaxun.yang@flygoat.com
      Fixes: 02371991 ("x86/CPU/AMD: Set the CPB bit unconditionally on F17h")
      Link: http://lkml.kernel.org/r/20190522221745.GA15789@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com
      
      
      [ Minor edits to the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a35e7822
    • Dan Carpenter's avatar
      mISDN: make sure device name is NUL terminated · 8e5666cd
      Dan Carpenter authored
      [ Upstream commit ccfb62f2
      
       ]
      
      The user can change the device_name with the IMSETDEVNAME ioctl, but we
      need to ensure that the user's name is NUL terminated.  Otherwise it
      could result in a buffer overflow when we copy the name back to the user
      with IMGETDEVINFO ioctl.
      
      I also changed two strcpy() calls which handle the name to strscpy().
      Hopefully, there aren't any other ways to create a too long name, but
      it's nice to do this as a kernel hardening measure.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8e5666cd
    • Jia-Ju Bai's avatar
      usb: xhci: Fix a potential null pointer dereference in xhci_debugfs_create_endpoint() · f3885eec
      Jia-Ju Bai authored
      [ Upstream commit 5bce256f
      
       ]
      
      In xhci_debugfs_create_slot(), kzalloc() can fail and
      dev->debugfs_private will be NULL.
      In xhci_debugfs_create_endpoint(), dev->debugfs_private is used without
      any null-pointer check, and can cause a null pointer dereference.
      
      To fix this bug, a null-pointer check is added in
      xhci_debugfs_create_endpoint().
      
      This bug is found by a runtime fuzzing tool named FIZZER written by us.
      
      [subjet line change change, add potential -Mathais]
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f3885eec
    • Anju T Sudhakar's avatar
      powerpc/powernv: Return for invalid IMC domain · 930d31a6
      Anju T Sudhakar authored
      [ Upstream commit b59bd352 ]
      
      Currently init_imc_pmu() can fail either because we try to register an
      IMC unit with an invalid domain (i.e an IMC node not supported by the
      kernel) or something went wrong while registering a valid IMC unit. In
      both the cases kernel provides a 'Register failed' error message.
      
      For example when trace-imc node is not supported by the kernel, but
      skiboot advertises a trace-imc node we print:
      
        IMC Unknown Device type
        IMC PMU (null) Register failed
      
      To avoid confusion just print the unknown device type message, before
      attempting PMU registration, so the second message isn't printed.
      
      Fixes: 8f95faaa
      
       ("powerpc/powernv: Detect and create IMC device")
      Reported-by: default avatarPavaman Subramaniyam <pavsubra@in.ibm.com>
      Signed-off-by: default avatarAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Reviewed-by: default avatarMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      [mpe: Reword change log a bit]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      930d31a6
    • Tony Lindgren's avatar
      clk: ti: clkctrl: Fix clkdm_clk handling · 00ed897d
      Tony Lindgren authored
      [ Upstream commit 1cc54078 ]
      
      We need to always call clkdm_clk_enable() and clkdm_clk_disable() even
      the clkctrl clock(s) enabled for the domain do not have any gate register
      bits. Otherwise clockdomains may never get enabled except when devices get
      probed with the legacy "ti,hwmods" devicetree property.
      
      Fixes: 88a17252
      
       ("clk: ti: add support for clkctrl clocks")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      00ed897d
    • Jeffrin Jose T's avatar
      selftests: netfilter: missing error check when setting up veth interface · ef4ffa0f
      Jeffrin Jose T authored
      [ Upstream commit 82ce6eb1
      
       ]
      
      A test for the basic NAT functionality uses ip command which needs veth
      device. There is a condition where the kernel support for veth is not
      compiled into the kernel and the test script breaks. This patch contains
      code for reasonable error display and correct code exit.
      Signed-off-by: default avatarJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ef4ffa0f
    • YueHaibing's avatar
      ipvs: Fix use-after-free in ip_vs_in · 61c83de6
      YueHaibing authored
      [ Upstream commit 719c7d56
      
       ]
      
      BUG: KASAN: use-after-free in ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
      Read of size 4 at addr ffff8881e9b26e2c by task sshd/5603
      
      CPU: 0 PID: 5603 Comm: sshd Not tainted 4.19.39+ #30
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      Call Trace:
       dump_stack+0x71/0xab
       print_address_description+0x6a/0x270
       kasan_report+0x179/0x2c0
       ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
       ip_vs_in+0xd8/0x170 [ip_vs]
       nf_hook_slow+0x5f/0xe0
       __ip_local_out+0x1d5/0x250
       ip_local_out+0x19/0x60
       __tcp_transmit_skb+0xba1/0x14f0
       tcp_write_xmit+0x41f/0x1ed0
       ? _copy_from_iter_full+0xca/0x340
       __tcp_push_pending_frames+0x52/0x140
       tcp_sendmsg_locked+0x787/0x1600
       ? tcp_sendpage+0x60/0x60
       ? inet_sk_set_state+0xb0/0xb0
       tcp_sendmsg+0x27/0x40
       sock_sendmsg+0x6d/0x80
       sock_write_iter+0x121/0x1c0
       ? sock_sendmsg+0x80/0x80
       __vfs_write+0x23e/0x370
       vfs_write+0xe7/0x230
       ksys_write+0xa1/0x120
       ? __ia32_sys_read+0x50/0x50
       ? __audit_syscall_exit+0x3ce/0x450
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7ff6f6147c60
      Code: 73 01 c3 48 8b 0d 28 12 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 5d 73 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83
      RSP: 002b:00007ffd772ead18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000034 RCX: 00007ff6f6147c60
      RDX: 0000000000000034 RSI: 000055df30a31270 RDI: 0000000000000003
      RBP: 000055df30a31270 R08: 0000000000000000 R09: 0000000000000000
      R10: 00007ffd772ead70 R11: 0000000000000246 R12: 00007ffd772ead74
      R13: 00007ffd772eae20 R14: 00007ffd772eae24 R15: 000055df2f12ddc0
      
      Allocated by task 6052:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x10a/0x220
       ops_init+0x97/0x190
       register_pernet_operations+0x1ac/0x360
       register_pernet_subsys+0x24/0x40
       0xffffffffc0ea016d
       do_one_initcall+0x8b/0x253
       do_init_module+0xe3/0x335
       load_module+0x2fc0/0x3890
       __do_sys_finit_module+0x192/0x1c0
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 6067:
       __kasan_slab_free+0x130/0x180
       kfree+0x90/0x1a0
       ops_free_list.part.7+0xa6/0xc0
       unregister_pernet_operations+0x18b/0x1f0
       unregister_pernet_subsys+0x1d/0x30
       ip_vs_cleanup+0x1d/0xd2f [ip_vs]
       __x64_sys_delete_module+0x20c/0x300
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8881e9b26600 which belongs to the cache kmalloc-4096 of size 4096
      The buggy address is located 2092 bytes inside of 4096-byte region [ffff8881e9b26600, ffff8881e9b27600)
      The buggy address belongs to the page:
      page:ffffea0007a6c800 count:1 mapcount:0 mapping:ffff888107c0e600 index:0x0 compound_mapcount: 0
      flags: 0x17ffffc0008100(slab|head)
      raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff888107c0e600
      raw: 0000000000000000 0000000080070007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      while unregistering ipvs module, ops_free_list calls
      __ip_vs_cleanup, then nf_unregister_net_hooks be called to
      do remove nf hook entries. It need a RCU period to finish,
      however net->ipvs is set to NULL immediately, which will
      trigger NULL pointer dereference when a packet is hooked
      and handled by ip_vs_in where net->ipvs is dereferenced.
      
      Another scene is ops_free_list call ops_free to free the
      net_generic directly while __ip_vs_cleanup finished, then
      calling ip_vs_in will triggers use-after-free.
      
      This patch moves nf_unregister_net_hooks from __ip_vs_cleanup()
      to __ip_vs_dev_cleanup(),  where rcu_barrier() is called by
      unregister_pernet_device -> unregister_pernet_operations,
      that will do the needed grace period.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: efe41606
      
       ("ipvs: convert to use pernet nf_hook api")
      Suggested-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      61c83de6
    • Jagdish Motwani's avatar
      netfilter: nf_queue: fix reinject verdict handling · 883ce78c
      Jagdish Motwani authored
      [ Upstream commit 946c0d8e ]
      
      This patch fixes netfilter hook traversal when there are more than 1 hooks
      returning NF_QUEUE verdict. When the first queue reinjects the packet,
      'nf_reinject' starts traversing hooks with a proper hook_index. However,
      if it again receives a NF_QUEUE verdict (by some other netfilter hook), it
      queues the packet with a wrong hook_index. So, when the second queue
      reinjects the packet, it re-executes hooks in between.
      
      Fixes: 960632ec
      
       ("netfilter: convert hook list to an array")
      Signed-off-by: default avatarJagdish Motwani <jagdish.motwani@sophos.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      883ce78c
    • Stephane Eranian's avatar
      perf/x86/intel/ds: Fix EVENT vs. UEVENT PEBS constraints · 5a9c29cc
      Stephane Eranian authored
      [ Upstream commit 23e3983a ]
      
      This patch fixes an bug revealed by the following commit:
      
        6b89d4c1
      
       ("perf/x86/intel: Fix INTEL_FLAGS_EVENT_CONSTRAINT* masking")
      
      That patch modified INTEL_FLAGS_EVENT_CONSTRAINT() to only look at the event code
      when matching a constraint. If code+umask were needed, then the
      INTEL_FLAGS_UEVENT_CONSTRAINT() macro was needed instead.
      This broke with some of the constraints for PEBS events.
      
      Several of them, including the one used for cycles:p, cycles:pp, cycles:ppp
      fell in that category and caused the event to be rejected in PEBS mode.
      In other words, on some platforms a cmdline such as:
      
        $ perf top -e cycles:pp
      
      would fail with -EINVAL.
      
      This patch fixes this bug by properly using INTEL_FLAGS_UEVENT_CONSTRAINT()
      when needed in the PEBS constraint tables.
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kan.liang@intel.com
      Link: http://lkml.kernel.org/r/20190521005246.423-1-eranian@google.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5a9c29cc
    • Dan Carpenter's avatar
      Staging: vc04_services: Fix a couple error codes · dd9b6de7
      Dan Carpenter authored
      [ Upstream commit ca4e4efb ]
      
      These are accidentally returning positive EINVAL instead of negative
      -EINVAL.  Some of the callers treat positive values as success.
      
      Fixes: 7b3ad5ab
      
       ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dd9b6de7
    • Maxime Chevallier's avatar
      net: mvpp2: prs: Use the correct helpers when removing all VID filters · 97605ba6
      Maxime Chevallier authored
      [ Upstream commit 6b7a3430 ]
      
      When removing all VID filters, the mvpp2_prs_vid_entry_remove would be
      called with the TCAM id incorrectly used as a VID, causing the wrong
      TCAM entries to be invalidated.
      
      Fix this by directly invalidating entries in the VID range.
      
      Fixes: 56beda3d
      
       ("net: mvpp2: Add hardware offloading for VLAN filtering")
      Suggested-by: default avatarYuri Chipchev <yuric@marvell.com>
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97605ba6
    • Maxime Chevallier's avatar
      net: mvpp2: prs: Fix parser range for VID filtering · b6a1eabf
      Maxime Chevallier authored
      [ Upstream commit 46b0090a ]
      
      VID filtering is implemented in the Header Parser, with one range of 11
      vids being assigned for each no-loopback port.
      
      Make sure we use the per-port range when looking for existing entries in
      the Parser.
      
      Since we used a global range instead of a per-port one, this causes VIDs
      to be removed from the whitelist from all ports of the same PPv2
      instance.
      
      Fixes: 56beda3d
      
       ("net: mvpp2: Add hardware offloading for VLAN filtering")
      Suggested-by: default avatarYuri Chipchev <yuric@marvell.com>
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6a1eabf
    • Alaa Hleihel's avatar
      net/mlx5: Avoid reloading already removed devices · 4642a659
      Alaa Hleihel authored
      Prior to reloading a device we must first verify that it was not already
      removed. Otherwise, the attempt to remove the device will do nothing, and
      in that case we will end up proceeding with adding an new device that no
      one was expecting to remove, leaving behind used resources such as EQs that
      causes a failure to destroy comp EQs and syndrome (0x30f433).
      
      Fix that by making sure that we try to remove and add a device (based on a
      protocol) only if the device is already added.
      
      Fixes: c5447c70
      
       ("net/mlx5: E-Switch, Reload IB interface when switching devlink modes")
      Signed-off-by: default avatarAlaa Hleihel <alaa@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4642a659
    • Stephen Barber's avatar
      vsock/virtio: set SOCK_DONE on peer shutdown · 1b201b63
      Stephen Barber authored
      [ Upstream commit 42f5cda5
      
       ]
      
      Set the SOCK_DONE flag to match the TCP_CLOSING state when a peer has
      shut down and there is nothing left to read.
      
      This fixes the following bug:
      1) Peer sends SHUTDOWN(RDWR).
      2) Socket enters TCP_CLOSING but SOCK_DONE is not set.
      3) read() returns -ENOTCONN until close() is called, then returns 0.
      Signed-off-by: default avatarStephen Barber <smbarber@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b201b63
    • Xin Long's avatar
      tipc: purge deferredq list for each grp member in tipc_group_delete · b86a5ccd
      Xin Long authored
      [ Upstream commit 5cf02612 ]
      
      Syzbot reported a memleak caused by grp members' deferredq list not
      purged when the grp is be deleted.
      
      The issue occurs when more(msg_grp_bc_seqno(hdr), m->bc_rcv_nxt) in
      tipc_group_filter_msg() and the skb will stay in deferredq.
      
      So fix it by calling __skb_queue_purge for each member's deferredq
      in tipc_group_delete() when a tipc sk leaves the grp.
      
      Fixes: b87a5ea3
      
       ("tipc: guarantee group unicast doesn't bypass group broadcast")
      Reported-by: syzbot+78fbe679c8ca8d264a8d@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b86a5ccd
    • John Paul Adrian Glaubitz's avatar
      sunhv: Fix device naming inconsistency between sunhv_console and sunhv_reg · e1b0c311
      John Paul Adrian Glaubitz authored
      [ Upstream commit 07a6d63e ]
      
      In d5a2aa24
      
      , the name in struct console sunhv_console was changed from "ttyS"
      to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged.
      
      This results in the hypervisor console device to be listed as "ttyHV0" under
      /proc/consoles while the device node is still named "ttyS0":
      
      root@osaka:~# cat /proc/consoles
      ttyHV0               -W- (EC p  )    4:64
      tty0                 -WU (E     )    4:1
      root@osaka:~# readlink /sys/dev/char/4:64
      ../../devices/root/f02836f0/f0285690/tty/ttyS0
      root@osaka:~#
      
      This means that any userland code which tries to determine the name of the
      device file of the hypervisor console device can not rely on the information
      provided by /proc/consoles. In particular, booting current versions of debian-
      installer inside a SPARC LDOM will fail with the installer unable to determine
      the console device.
      
      After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well,
      the inconsistency is fixed and it is possible again to determine the name
      of the device file of the hypervisor console device by reading the contents
      of /proc/console:
      
      root@osaka:~# cat /proc/consoles
      ttyHV0               -W- (EC p  )    4:64
      tty0                 -WU (E     )    4:1
      root@osaka:~# readlink /sys/dev/char/4:64
      ../../devices/root/f02836f0/f0285690/tty/ttyHV0
      root@osaka:~#
      
      With this change, debian-installer works correctly when installing inside
      a SPARC LDOM.
      Signed-off-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1b0c311
    • Neil Horman's avatar
      sctp: Free cookie before we memdup a new one · d7fcb54e
      Neil Horman authored
      [ Upstream commit ce950f10
      
       ]
      
      Based on comments from Xin, even after fixes for our recent syzbot
      report of cookie memory leaks, its possible to get a resend of an INIT
      chunk which would lead to us leaking cookie memory.
      
      To ensure that we don't leak cookie memory, free any previously
      allocated cookie first.
      
      Change notes
      v1->v2
      update subsystem tag in subject (davem)
      repeat kfree check for peer_random and peer_hmacs (xin)
      
      v2->v3
      net->sctp
      also free peer_chunks
      
      v3->v4
      fix subject tags
      
      v4->v5
      remove cut line
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: Xin Long <lucien.xin@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7fcb54e
    • Young Xiao's avatar
      nfc: Ensure presence of required attributes in the deactivate_target handler · 4bb4ba36
      Young Xiao authored
      [ Upstream commit 385097a3
      
       ]
      
      Check that the NFC_ATTR_TARGET_INDEX attributes (in addition to
      NFC_ATTR_DEVICE_INDEX) are provided by the netlink client prior to
      accessing them. This prevents potential unhandled NULL pointer dereference
      exceptions which can be triggered by malicious user-mode programs,
      if they omit one or both of these attributes.
      Signed-off-by: default avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bb4ba36
    • Taehee Yoo's avatar
      net: openvswitch: do not free vport if register_netdevice() is failed. · 7530c3f3
      Taehee Yoo authored
      [ Upstream commit 309b6697 ]
      
      In order to create an internal vport, internal_dev_create() is used and
      that calls register_netdevice() internally.
      If register_netdevice() fails, it calls dev->priv_destructor() to free
      private data of netdev. actually, a private data of this is a vport.
      
      Hence internal_dev_create() should not free and use a vport after failure
      of register_netdevice().
      
      Test command
          ovs-dpctl add-dp bonding_masters
      
      Splat looks like:
      [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G    B             5.2.0-rc3+ #240
      [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch]
      [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4
      [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206
      [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704
      [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560
      [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881
      [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000
      [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698
      [ 1035.777709] FS:  00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      [ 1035.777709] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0
      [ 1035.777709] Call Trace:
      [ 1035.777709]  ovs_vport_add+0x267/0x4f0 [openvswitch]
      [ 1035.777709]  new_vport+0x15/0x1e0 [openvswitch]
      [ 1035.777709]  ovs_vport_cmd_new+0x567/0xd10 [openvswitch]
      [ 1035.777709]  ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch]
      [ 1035.777709]  ? __kmalloc+0x131/0x2e0
      [ 1035.777709]  ? genl_family_rcv_msg+0xa54/0x1030
      [ 1035.777709]  genl_family_rcv_msg+0x63a/0x1030
      [ 1035.777709]  ? genl_unregister_family+0x630/0x630
      [ 1035.841681]  ? debug_show_all_locks+0x2d0/0x2d0
      [ ... ]
      
      Fixes: cf124db5
      
       ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7530c3f3
    • Linus Walleij's avatar
      net: dsa: rtl8366: Fix up VLAN filtering · fc762c99
      Linus Walleij authored
      [ Upstream commit 760c80b7 ]
      
      We get this regression when using RTL8366RB as part of a bridge
      with OpenWrt:
      
      WARNING: CPU: 0 PID: 1347 at net/switchdev/switchdev.c:291
      	 switchdev_port_attr_set_now+0x80/0xa4
      lan0: Commit of attribute (id=7) failed.
      (...)
      realtek-smi switch lan0: failed to initialize vlan filtering on this port
      
      This is because it is trying to disable VLAN filtering
      on VLAN0, as we have forgot to add 1 to the port number
      to get the right VLAN in rtl8366_vlan_filtering(): when
      we initialize the VLAN we associate VLAN1 with port 0,
      VLAN2 with port 1 etc, so we need to add 1 to the port
      offset.
      
      Fixes: d8652956
      
       ("net: dsa: realtek-smi: Add Realtek SMI driver")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc762c99
    • Eric Dumazet's avatar
      neigh: fix use-after-free read in pneigh_get_next · 103835df
      Eric Dumazet authored
      [ Upstream commit f3e92cb8 ]
      
      Nine years ago, I added RCU handling to neighbours, not pneighbours.
      (pneigh are not commonly used)
      
      Unfortunately I missed that /proc dump operations would use a
      common entry and exit point : neigh_seq_start() and neigh_seq_stop()
      
      We need to read_lock(tbl->lock) or risk use-after-free while
      iterating the pneigh structures.
      
      We might later convert pneigh to RCU and revert this patch.
      
      sysbot reported :
      
      BUG: KASAN: use-after-free in pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
      Read of size 8 at addr ffff888097f2a700 by task syz-executor.0/9825
      
      CPU: 1 PID: 9825 Comm: syz-executor.0 Not tainted 5.2.0-rc4+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
       neigh_seq_next+0xdb/0x210 net/core/neighbour.c:3240
       seq_read+0x9cf/0x1110 fs/seq_file.c:258
       proc_reg_read+0x1fc/0x2c0 fs/proc/inode.c:221
       do_loop_readv_writev fs/read_write.c:714 [inline]
       do_loop_readv_writev fs/read_write.c:701 [inline]
       do_iter_read+0x4a4/0x660 fs/read_write.c:935
       vfs_readv+0xf0/0x160 fs/read_write.c:997
       kernel_readv fs/splice.c:359 [inline]
       default_file_splice_read+0x475/0x890 fs/splice.c:414
       do_splice_to+0x127/0x180 fs/splice.c:877
       splice_direct_to_actor+0x2d2/0x970 fs/splice.c:954
       do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
       do_sendfile+0x597/0xd00 fs/read_write.c:1464
       __do_sys_sendfile64 fs/read_write.c:1525 [inline]
       __se_sys_sendfile64 fs/read_write.c:1511 [inline]
       __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4592c9
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f4aab51dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00000000004592c9
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000080000000 R11: 0000000000000246 R12: 00007f4aab51e6d4
      R13: 00000000004c689d R14: 00000000004db828 R15: 00000000ffffffff
      
      Allocated by task 9827:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       __do_kmalloc mm/slab.c:3660 [inline]
       __kmalloc+0x15c/0x740 mm/slab.c:3669
       kmalloc include/linux/slab.h:552 [inline]
       pneigh_lookup+0x19c/0x4a0 net/core/neighbour.c:731
       arp_req_set_public net/ipv4/arp.c:1010 [inline]
       arp_req_set+0x613/0x720 net/ipv4/arp.c:1026
       arp_ioctl+0x652/0x7f0 net/ipv4/arp.c:1226
       inet_ioctl+0x2a0/0x340 net/ipv4/af_inet.c:926
       sock_do_ioctl+0xd8/0x2f0 net/socket.c:1043
       sock_ioctl+0x3ed/0x780 net/socket.c:1194
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 9824:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       pneigh_ifdown_and_unlock net/core/neighbour.c:812 [inline]
       __neigh_ifdown+0x236/0x2f0 net/core/neighbour.c:356
       neigh_ifdown+0x20/0x30 net/core/neighbour.c:372
       arp_ifdown+0x1d/0x21 net/ipv4/arp.c:1274
       inetdev_destroy net/ipv4/devinet.c:319 [inline]
       inetdev_event+0xa14/0x11f0 net/ipv4/devinet.c:1544
       notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
       __raw_notifier_call_chain kernel/notifier.c:396 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
       call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
       call_netdevice_notifiers net/core/dev.c:1775 [inline]
       rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8178
       rollback_registered+0x109/0x1d0 net/core/dev.c:8220
       unregister_netdevice_queue net/core/dev.c:9267 [inline]
       unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9260
       unregister_netdevice include/linux/netdevice.h:2631 [inline]
       __tun_detach+0xd8a/0x1040 drivers/net/tun.c:724
       tun_detach drivers/net/tun.c:741 [inline]
       tun_chr_close+0xe0/0x180 drivers/net/tun.c:3451
       __fput+0x2ff/0x890 fs/file_table.c:280
       ____fput+0x16/0x20 fs/file_table.c:313
       task_work_run+0x145/0x1c0 kernel/task_work.c:113
       tracehook_notify_resume include/linux/tracehook.h:185 [inline]
       exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:168
       prepare_exit_to_usermode arch/x86/entry/common.c:199 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
       do_syscall_64+0x58e/0x680 arch/x86/entry/common.c:304
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888097f2a700
       which belongs to the cache kmalloc-64 of size 64
      The buggy address is located 0 bytes inside of
       64-byte region [ffff888097f2a700, ffff888097f2a740)
      The buggy address belongs to the page:
      page:ffffea00025fca80 refcount:1 mapcount:0 mapping:ffff8880aa400340 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea000250d548 ffffea00025726c8 ffff8880aa400340
      raw: 0000000000000000 ffff888097f2a000 0000000100000020 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888097f2a600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
       ffff888097f2a680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff888097f2a700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                         ^
       ffff888097f2a780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff888097f2a800: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      
      Fixes: 767e97e1
      
       ("neigh: RCU conversion of struct neighbour")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      103835df
    • Jeremy Sowden's avatar
      lapb: fixed leak of control-blocks. · 2980196d
      Jeremy Sowden authored
      [ Upstream commit 6be8e297
      
       ]
      
      lapb_register calls lapb_create_cb, which initializes the control-
      block's ref-count to one, and __lapb_insert_cb, which increments it when
      adding the new block to the list of blocks.
      
      lapb_unregister calls __lapb_remove_cb, which decrements the ref-count
      when removing control-block from the list of blocks, and calls lapb_put
      itself to decrement the ref-count before returning.
      
      However, lapb_unregister also calls __lapb_devtostruct to look up the
      right control-block for the given net_device, and __lapb_devtostruct
      also bumps the ref-count, which means that when lapb_unregister returns
      the ref-count is still 1 and the control-block is leaked.
      
      Call lapb_put after __lapb_devtostruct to fix leak.
      
      Reported-by: syzbot+afb980676c836b4a0afa@syzkaller.appspotmail.com
      Signed-off-by: default avatarJeremy Sowden <jeremy@azazel.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2980196d
    • Eric Dumazet's avatar
      ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero · 7eadfacd
      Eric Dumazet authored
      [ Upstream commit 65a3c497 ]
      
      Before taking a refcount, make sure the object is not already
      scheduled for deletion.
      
      Same fix is needed in ipv6_flowlabel_opt()
      
      Fixes: 18367681
      
       ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7eadfacd
    • Haiyang Zhang's avatar
      hv_netvsc: Set probe mode to sync · a5ae5920
      Haiyang Zhang authored
      [ Upstream commit 9a33629b ]
      
      For better consistency of synthetic NIC names, we set the probe mode to
      PROBE_FORCE_SYNCHRONOUS. So the names can be aligned with the vmbus
      channel offer sequence.
      
      Fixes: af0a5646
      
       ("use the new async probing feature for the hyperv drivers")
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5ae5920
    • Ivan Vecera's avatar
      be2net: Fix number of Rx queues used for flow hashing · 674dc77b
      Ivan Vecera authored
      [ Upstream commit 718f4a25 ]
      
      Number of Rx queues used for flow hashing returned by the driver is
      incorrect and this bug prevents user to use the last Rx queue in
      indirection table.
      
      Let's say we have a NIC with 6 combined queues:
      
      [root@sm-03 ~]# ethtool -l enp4s0f0
      Channel parameters for enp4s0f0:
      Pre-set maximums:
      RX:             5
      TX:             5
      Other:          0
      Combined:       6
      Current hardware settings:
      RX:             0
      TX:             0
      Other:          0
      Combined:       6
      
      Default indirection table maps all (6) queues equally but the driver
      reports only 5 rings available.
      
      [root@sm-03 ~]# ethtool -x enp4s0f0
      RX flow hash indirection table for enp4s0f0 with 5 RX ring(s):
          0:      0     1     2     3     4     5     0     1
          8:      2     3     4     5     0     1     2     3
         16:      4     5     0     1     2     3     4     5
         24:      0     1     2     3     4     5     0     1
      ...
      
      Now change indirection table somehow:
      
      [root@sm-03 ~]# ethtool -X enp4s0f0 weight 1 1
      [root@sm-03 ~]# ethtool -x enp4s0f0
      RX flow hash indirection table for enp4s0f0 with 6 RX ring(s):
          0:      0     0     0     0     0     0     0     0
      ...
         64:      1     1     1     1     1     1     1     1
      ...
      
      Now it is not possible to change mapping back to equal (default) state:
      
      [root@sm-03 ~]# ethtool -X enp4s0f0 equal 6
      Cannot set RX flow hash configuration: Invalid argument
      
      Fixes: 594ad54a
      
       ("be2net: Add support for setting and getting rx flow hash options")
      Reported-by: default avatarTianhao <tizhao@redhat.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      674dc77b
    • Eric Dumazet's avatar
      ax25: fix inconsistent lock state in ax25_destroy_timer · 10faaa35
      Eric Dumazet authored
      [ Upstream commit d4d5d8e8
      
       ]
      
      Before thread in process context uses bh_lock_sock()
      we must disable bh.
      
      sysbot reported :
      
      WARNING: inconsistent lock state
      5.2.0-rc3+ #32 Not tainted
      
      inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      blkid/26581 [HC0[0]:SC1[1]:HE1:SE0] takes:
      00000000e0da85ee (slock-AF_AX25){+.?.}, at: spin_lock include/linux/spinlock.h:338 [inline]
      00000000e0da85ee (slock-AF_AX25){+.?.}, at: ax25_destroy_timer+0x53/0xc0 net/ax25/af_ax25.c:275
      {SOFTIRQ-ON-W} state was registered at:
        lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4303
        __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
        _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
        spin_lock include/linux/spinlock.h:338 [inline]
        ax25_rt_autobind+0x3ca/0x720 net/ax25/ax25_route.c:429
        ax25_connect.cold+0x30/0xa4 net/ax25/af_ax25.c:1221
        __sys_connect+0x264/0x330 net/socket.c:1834
        __do_sys_connect net/socket.c:1845 [inline]
        __se_sys_connect net/socket.c:1842 [inline]
        __x64_sys_connect+0x73/0xb0 net/socket.c:1842
        do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      irq event stamp: 2272
      hardirqs last  enabled at (2272): [<ffffffff810065f3>] trace_hardirqs_on_thunk+0x1a/0x1c
      hardirqs last disabled at (2271): [<ffffffff8100660f>] trace_hardirqs_off_thunk+0x1a/0x1c
      softirqs last  enabled at (1522): [<ffffffff87400654>] __do_softirq+0x654/0x94c kernel/softirq.c:320
      softirqs last disabled at (2267): [<ffffffff81449010>] invoke_softirq kernel/softirq.c:374 [inline]
      softirqs last disabled at (2267): [<ffffffff81449010>] irq_exit+0x180/0x1d0 kernel/softirq.c:414
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(slock-AF_AX25);
        <Interrupt>
          lock(slock-AF_AX25);
      
       *** DEADLOCK ***
      
      1 lock held by blkid/26581:
       #0: 0000000010fd154d ((&ax25->dtimer)){+.-.}, at: lockdep_copy_map include/linux/lockdep.h:175 [inline]
       #0: 0000000010fd154d ((&ax25->dtimer)){+.-.}, at: call_timer_fn+0xe0/0x720 kernel/time/timer.c:1312
      
      stack backtrace:
      CPU: 1 PID: 26581 Comm: blkid Not tainted 5.2.0-rc3+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_usage_bug.cold+0x393/0x4a2 kernel/locking/lockdep.c:2935
       valid_state kernel/locking/lockdep.c:2948 [inline]
       mark_lock_irq kernel/locking/lockdep.c:3138 [inline]
       mark_lock+0xd46/0x1370 kernel/locking/lockdep.c:3513
       mark_irqflags kernel/locking/lockdep.c:3391 [inline]
       __lock_acquire+0x159f/0x5490 kernel/locking/lockdep.c:3745
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4303
       __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
       _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
       spin_lock include/linux/spinlock.h:338 [inline]
       ax25_destroy_timer+0x53/0xc0 net/ax25/af_ax25.c:275
       call_timer_fn+0x193/0x720 kernel/time/timer.c:1322
       expire_timers kernel/time/timer.c:1366 [inline]
       __run_timers kernel/time/timer.c:1685 [inline]
       __run_timers kernel/time/timer.c:1653 [inline]
       run_timer_softirq+0x66f/0x1740 kernel/time/timer.c:1698
       __do_softirq+0x25c/0x94c kernel/softirq.c:293
       invoke_softirq kernel/softirq.c:374 [inline]
       irq_exit+0x180/0x1d0 kernel/softirq.c:414
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x13b/0x550 arch/x86/kernel/apic/apic.c:1068
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806
       </IRQ>
      RIP: 0033:0x7f858d5c3232
      Code: 8b 61 08 48 8b 84 24 d8 00 00 00 4c 89 44 24 28 48 8b ac 24 d0 00 00 00 4c 8b b4 24 e8 00 00 00 48 89 7c 24 68 48 89 4c 24 78 <48> 89 44 24 58 8b 84 24 e0 00 00 00 89 84 24 84 00 00 00 8b 84 24
      RSP: 002b:00007ffcaf0cf5c0 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      RAX: 00007f858d7d27a8 RBX: 00007f858d7d8820 RCX: 00007f858d3940d8
      RDX: 00007ffcaf0cf798 RSI: 00000000f5e616f3 RDI: 00007f858d394fee
      RBP: 0000000000000000 R08: 00007ffcaf0cf780 R09: 00007f858d7db480
      R10: 0000000000000000 R11: 0000000009691a75 R12: 0000000000000005
      R13: 00000000f5e616f3 R14: 0000000000000000 R15: 00007ffcaf0cf798
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10faaa35
  2. 19 Jun, 2019 3 commits