1. 10 7月, 2019 17 次提交
    • H
      drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable() · 3b60f98e
      Hsin-Yi Wang 提交于
      [ Upstream commit 2458d9d6d94be982b917e93c61a89b4426f32e31 ]
      
      mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
      needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is
      called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called
      after last irq, it will timeout with this message: "vblank wait timed out
      on crtc 0". This happens sometimes when turning off the screen.
      
      In drm_atomic_helper.c#disable_outputs(),
      the calling sequence when turning off the screen is:
      
      1. mtk_dsi_encoder_disable()
           --> mtk_output_dsi_disable()
             --> mtk_dsi_stop();  /* sometimes make vblank timeout in
                                     atomic_disable */
             --> mtk_dsi_poweroff();
      2. mtk_drm_crtc_atomic_disable()
           --> drm_crtc_wait_one_vblank();
           ...
             --> mtk_dsi_ddp_stop()
               --> mtk_dsi_poweroff();
      
      mtk_dsi_poweroff() has reference count design, change to make
      mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0.
      
      Fixes: 0707632b ("drm/mediatek: update DSI sub driver flow for sending commands to panel")
      Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b60f98e
    • H
      drm/mediatek: clear num_pipes when unbind driver · 34e5e1c4
      Hsin-Yi Wang 提交于
      [ Upstream commit a4cd1d2b016d5d043ab2c4b9c4ec50a5805f5396 ]
      
      num_pipes is used for mutex created in mtk_drm_crtc_create(). If we
      don't clear num_pipes count, when rebinding driver, the count will
      be accumulated. From mtk_disp_mutex_get(), there can only be at most
      10 mutex id. Clear this number so it starts from 0 in every rebind.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      34e5e1c4
    • H
      drm/mediatek: call drm_atomic_helper_shutdown() when unbinding driver · a8a86e9a
      Hsin-Yi Wang 提交于
      [ Upstream commit cf49b24ffa62766f8f04cd1c4cf17b75d29b240a ]
      
      shutdown all CRTC when unbinding drm driver.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a8a86e9a
    • H
      drm/mediatek: unbind components in mtk_drm_unbind() · 79e095d2
      Hsin-Yi Wang 提交于
      [ Upstream commit f0fd848342802bc0f74620d387eead53e8905804 ]
      
      Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
      trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
      won't actually unbind components. During the next bind,
      mtk_drm_kms_init() is called, and the components are added back.
      
      .unbind() should call mtk_drm_kms_deinit() to unbind components.
      
      And since component_master_del() in .remove() will trigger .unbind(),
      which will also unregister device, it's fine to remove original functions
      called here.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      79e095d2
    • H
      drm/mediatek: fix unbind functions · 319f4699
      Hsin-Yi Wang 提交于
      [ Upstream commit 8fd7a37b191f93737f6280a9b5de65f98acc12c9 ]
      
      detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
      attach it again.
      
      Fixes: 2e54c14e ("drm/mediatek: Add DSI sub driver")
      Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: NCK Hu <ck.hu@mediatek.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      319f4699
    • Y
      spi: bitbang: Fix NULL pointer dereference in spi_unregister_master · dbd94f49
      YueHaibing 提交于
      [ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
      
      If spi_register_master fails in spi_bitbang_start
      because device_add failure, We should return the
      error code other than 0, otherwise calling
      spi_bitbang_stop may trigger NULL pointer dereference
      like this:
      
      BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
      Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661
      
      CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       dump_stack+0xa9/0x10e
       ? __list_del_entry_valid+0x45/0xd0
       ? __list_del_entry_valid+0x45/0xd0
       __kasan_report+0x171/0x18d
       ? __list_del_entry_valid+0x45/0xd0
       kasan_report+0xe/0x20
       __list_del_entry_valid+0x45/0xd0
       spi_unregister_controller+0x99/0x1b0
       spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
       ? 0xffffffffc1128000
       ? klist_next+0x131/0x1e0
       ? driver_detach+0x40/0x40 [parport]
       port_check+0x3b/0x50 [parport]
       bus_for_each_dev+0x115/0x180
       ? subsys_dev_iter_exit+0x20/0x20
       __parport_register_driver+0x1f0/0x210 [parport]
       ? 0xffffffffc1150000
       do_one_initcall+0xb9/0x3b5
       ? perf_trace_initcall_level+0x270/0x270
       ? kasan_unpoison_shadow+0x30/0x40
       ? kasan_unpoison_shadow+0x30/0x40
       do_init_module+0xe0/0x330
       load_module+0x38eb/0x4270
       ? module_frob_arch_sections+0x20/0x20
       ? kernel_read_file+0x188/0x3f0
       ? find_held_lock+0x6d/0xd0
       ? fput_many+0x1a/0xe0
       ? __do_sys_finit_module+0x162/0x190
       __do_sys_finit_module+0x162/0x190
       ? __ia32_sys_init_module+0x40/0x40
       ? __mutex_unlock_slowpath+0xb4/0x3f0
       ? wait_for_completion+0x240/0x240
       ? vfs_write+0x160/0x2a0
       ? lockdep_hardirqs_off+0xb5/0x100
       ? mark_held_locks+0x1a/0x90
       ? do_syscall_64+0x14/0x2a0
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: 702a4879 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dbd94f49
    • V
      ASoC: ak4458: rstn_control - return a non-zero on error only · 3f8d3c95
      Viorel Suman 提交于
      [ Upstream commit 176a11834b65ec35e3b7a953f87fb9cc41309497 ]
      
      snd_soc_component_update_bits() may return 1 if operation
      was successful and the value of the register changed.
      Return a non-zero in ak4458_rstn_control for an error only.
      Signed-off-by: NShengjiu Wang <shengjiu.wang@nxp.com>
      Signed-off-by: NViorel Suman <viorel.suman@nxp.com>
      Reviewed-by: NDaniel Baluta <daniel.baluta@nxp.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3f8d3c95
    • L
      ASoC: soc-pcm: BE dai needs prepare when pause release after resume · 3c3dd68c
      Libin Yang 提交于
      [ Upstream commit 5087a8f17df868601cd7568299e91c28086d2b45 ]
      
      If playback/capture is paused and system enters S3, after system returns
      from suspend, BE dai needs to call prepare() callback when playback/capture
      is released from pause if RESUME_INFO flag is not set.
      
      Currently, the dpcm_be_dai_prepare() function will block calling prepare()
      if the pcm is in SND_SOC_DPCM_STATE_PAUSED state. This will cause the
      following test case fail if the pcm uses BE:
      
      playback -> pause -> S3 suspend -> S3 resume -> pause release
      
      The playback may exit abnormally when pause is released because the BE dai
      prepare() is not called.
      
      This patch allows dpcm_be_dai_prepare() to call dai prepare() callback in
      SND_SOC_DPCM_STATE_PAUSED state.
      Signed-off-by: NLibin Yang <libin.yang@intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3c3dd68c
    • V
      ASoC: ak4458: add return value for ak4458_probe · 4c31b4b4
      Viorel Suman 提交于
      [ Upstream commit a8dee20d792432740509237943700fbcfc230bad ]
      
      AK4458 is probed successfully even if AK4458 is not present - this
      is caused by probe function returning no error on i2c access failure.
      Return an error on probe if i2c access has failed.
      Signed-off-by: NShengjiu Wang <shengjiu.wang@nxp.com>
      Signed-off-by: NViorel Suman <viorel.suman@nxp.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c31b4b4
    • M
      ASoC : cs4265 : readable register too low · 0c19bcdb
      Matt Flax 提交于
      [ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
      
      The cs4265_readable_register function stopped short of the maximum
      register.
      
      An example bug is taken from :
      https://github.com/Audio-Injector/Ultra/issues/25
      
      Where alsactl store fails with :
      Cannot read control '2,0,0,C Data Buffer,0': Input/output error
      
      This patch fixes the bug by setting the cs4265 to have readable
      registers up to the maximum hardware register CS4265_MAX_REGISTER.
      Signed-off-by: NMatt Flax <flatmax@flatmax.org>
      Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0c19bcdb
    • F
      netfilter: nft_flow_offload: IPCB is only valid for ipv4 family · c549680e
      Florian Westphal 提交于
      commit 69aeb538587e087bfc81dd1f465eab3558ff3158 upstream.
      
      Guard this with a check vs. ipv4, IPCB isn't valid in ipv6 case.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c549680e
    • F
      netfilter: nft_flow_offload: don't offload when sequence numbers need adjustment · 041c181e
      Florian Westphal 提交于
      commit 91a9048f238063dde7feea752b9dd386f7e3808b upstream.
      
      We can't deal with tcp sequence number rewrite in flow_offload.
      While at it, simplify helper check, we only need to know if the extension
      is present, we don't need the helper data.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      041c181e
    • F
      netfilter: nft_flow_offload: set liberal tracking mode for tcp · 48f611ec
      Florian Westphal 提交于
      commit 8437a6209f76f85a2db1abb12a9bde2170801617 upstream.
      
      Without it, whenever a packet has to be pushed up the stack (e.g. because
      of mtu mismatch), then conntrack will flag packets as invalid, which in
      turn breaks NAT.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48f611ec
    • F
      netfilter: nf_flow_table: ignore DF bit setting · 3b2734bc
      Florian Westphal 提交于
      commit e75b3e1c9bc5b997d09bdf8eb72ab3dd3c1a7072 upstream.
      
      Its irrelevant if the DF bit is set or not, we must pass packet to
      stack in either case.
      
      If the DF bit is set, we must pass it to stack so the appropriate
      ICMP error can be generated.
      
      If the DF is not set, we must pass it to stack for fragmentation.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b2734bc
    • G
      md/raid0: Do not bypass blocking queue entered for raid0 bios · 869eec89
      Guilherme G. Piccoli 提交于
      ```--------------------------------------------------------------
      This patch is not on mainline and is meant to 4.19 stable *only*.
      After the patch description there's a reasoning about that.
      ```
      
      --------------------------------------------------------------
      
      Commit cd4a4ae4 ("block: don't use blocking queue entered for
      recursive bio submits") introduced the flag BIO_QUEUE_ENTERED in order
      split bios bypass the blocking queue entering routine and use the live
      non-blocking version. It was a result of an extensive discussion in
      a linux-block thread[0], and the purpose of this change was to prevent
      a hung task waiting on a reference to drop.
      
      Happens that md raid0 split bios all the time, and more important,
      it changes their underlying device to the raid member. After the change
      introduced by this flag's usage, we experience various crashes if a raid0
      member is removed during a large write. This happens because the bio
      reaches the live queue entering function when the queue of the raid0
      member is dying.
      
      A simple reproducer of this behavior is presented below:
      a) Build kernel v4.19.56-stable with CONFIG_BLK_DEV_THROTTLING=y.
      
      b) Create a raid0 md array with 2 NVMe devices as members, and mount
      it with an ext4 filesystem.
      
      c) Run the following oneliner (supposing the raid0 is mounted in /mnt):
      (dd of=/mnt/tmp if=/dev/zero bs=1M count=999 &); sleep 0.3;
      echo 1 > /sys/block/nvme1n1/device/device/remove
      (whereas nvme1n1 is the 2nd array member)
      
      This will trigger the following warning/oops:
      
      ------------[ cut here ]------------
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000155
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      RIP: 0010:blk_throtl_bio+0x45/0x970
      [...]
      Call Trace:
       generic_make_request_checks+0x1bf/0x690
       generic_make_request+0x64/0x3f0
       raid0_make_request+0x184/0x620 [raid0]
       ? raid0_make_request+0x184/0x620 [raid0]
       md_handle_request+0x126/0x1a0
       md_make_request+0x7b/0x180
       generic_make_request+0x19e/0x3f0
       submit_bio+0x73/0x140
      [...]
      
      This patch changes raid0 driver to fallback to the "old" blocking queue
      entering procedure, by clearing the BIO_QUEUE_ENTERED from raid0 bios.
      This prevents the crashes and restores the regular behavior of raid0
      arrays when a member is removed during a large write.
      
      [0] lore.kernel.org/linux-block/343bbbf6-64eb-879e-d19e-96aebb037d47@I-love.SAKURA.ne.jp
      
      ----------------------------
      Why this is not on mainline?
      ----------------------------
      
      The patch was originally submitted upstream in linux-raid and
      linux-block mailing-lists - it was initially accepted by Song Liu,
      but Christoph Hellwig[1] observed that there was a clean-up series
      ready to be accepted from Ming Lei[2] that fixed the same issue.
      
      The accepted patches from Ming's series in upstream are: commit
      47cdee29ef9d ("block: move blk_exit_queue into __blk_release_queue") and
      commit fe2008640ae3 ("block: don't protect generic_make_request_checks
      with blk_queue_enter"). Those patches basically do a clean-up in the
      block layer involving:
      
      1) Putting back blk_exit_queue() logic into __blk_release_queue(); that
      path was changed in the past and the logic from blk_exit_queue() was
      added to blk_cleanup_queue().
      
      2) Removing the guard/protection in generic_make_request_checks() with
      blk_queue_enter().
      
      The problem with Ming's series for -stable is that it relies in the
      legacy request IO path removal. So it's "backport-able" to v5.0+,
      but doing that for early versions (like 4.19) would incur in complex
      code changes. Hence, it was suggested by Christoph and Song Liu that
      this patch was submitted to stable only; otherwise merging it upstream
      would add code to fix a path removed in a subsequent commit.
      
      [1] lore.kernel.org/linux-block/20190521172258.GA32702@infradead.org
      [2] lore.kernel.org/linux-block/20190515030310.20393-1-ming.lei@redhat.com
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Ming Lei <ming.lei@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Fixes: cd4a4ae4 ("block: don't use blocking queue entered for recursive bio submits")
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@canonical.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      869eec89
    • G
      block: Fix a NULL pointer dereference in generic_make_request() · c9d8d3e9
      Guilherme G. Piccoli 提交于
      ```--------------------------------------------------------------
      This patch is not on mainline and is meant to 4.19 stable *only*.
      After the patch description there's a reasoning about that.
      ```
      
      --------------------------------------------------------------
      
      Commit 37f9579f ("blk-mq: Avoid that submitting a bio concurrently
      with device removal triggers a crash") introduced a NULL pointer
      dereference in generic_make_request(). The patch sets q to NULL and
      enter_succeeded to false; right after, there's an 'if (enter_succeeded)'
      which is not taken, and then the 'else' will dereference q in
      blk_queue_dying(q).
      
      This patch just moves the 'q = NULL' to a point in which it won't trigger
      the oops, although the semantics of this NULLification remains untouched.
      
      A simple test case/reproducer is as follows:
      a) Build kernel v4.19.56-stable with CONFIG_BLK_CGROUP=n.
      
      b) Create a raid0 md array with 2 NVMe devices as members, and mount
      it with an ext4 filesystem.
      
      c) Run the following oneliner (supposing the raid0 is mounted in /mnt):
      (dd of=/mnt/tmp if=/dev/zero bs=1M count=999 &); sleep 0.3;
      echo 1 > /sys/block/nvme1n1/device/device/remove
      (whereas nvme1n1 is the 2nd array member)
      
      This will trigger the following oops:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      RIP: 0010:generic_make_request+0x32b/0x400
      Call Trace:
       submit_bio+0x73/0x140
       ext4_io_submit+0x4d/0x60
       ext4_writepages+0x626/0xe90
       do_writepages+0x4b/0xe0
      [...]
      
      This patch has no functional changes and preserves the md/raid0 behavior
      when a member is removed before kernel v4.17.
      
      ----------------------------
      Why this is not on mainline?
      ----------------------------
      
      The patch was originally submitted upstream in linux-raid and
      linux-block mailing-lists - it was initially accepted by Song Liu,
      but Christoph Hellwig[0] observed that there was a clean-up series
      ready to be accepted from Ming Lei[1] that fixed the same issue.
      
      The accepted patches from Ming's series in upstream are: commit
      47cdee29ef9d ("block: move blk_exit_queue into __blk_release_queue") and
      commit fe2008640ae3 ("block: don't protect generic_make_request_checks
      with blk_queue_enter"). Those patches basically do a clean-up in the
      block layer involving:
      
      1) Putting back blk_exit_queue() logic into __blk_release_queue(); that
      path was changed in the past and the logic from blk_exit_queue() was
      added to blk_cleanup_queue().
      
      2) Removing the guard/protection in generic_make_request_checks() with
      blk_queue_enter().
      
      The problem with Ming's series for -stable is that it relies in the
      legacy request IO path removal. So it's "backport-able" to v5.0+,
      but doing that for early versions (like 4.19) would incur in complex
      code changes. Hence, it was suggested by Christoph and Song Liu that
      this patch was submitted to stable only; otherwise merging it upstream
      would add code to fix a path removed in a subsequent commit.
      
      [0] lore.kernel.org/linux-block/20190521172258.GA32702@infradead.org
      [1] lore.kernel.org/linux-block/20190515030310.20393-1-ming.lei@redhat.com
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Tested-by: NEric Ren <renzhengeek@gmail.com>
      Fixes: 37f9579f ("blk-mq: Avoid that submitting a bio concurrently with device removal triggers a crash")
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@canonical.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9d8d3e9
    • M
      Bluetooth: Fix faulty expression for minimum encryption key size check · 5dd6139a
      Matias Karhumaa 提交于
      commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream.
      
      Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is
      also allowed as stated in the comment.
      
      This bug caused connection problems with devices having maximum
      encryption key size of 7 octets (56-bit).
      
      Fixes: 693cd8ce3f88 ("Bluetooth: Fix regression with minimum encryption key size alignment")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997Signed-off-by: NMatias Karhumaa <matias.karhumaa@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dd6139a
  2. 03 7月, 2019 23 次提交
    • G
      Linux 4.19.57 · 1a059243
      Greg Kroah-Hartman 提交于
      1a059243
    • J
      arm64: insn: Fix ldadd instruction encoding · 3919d91f
      Jean-Philippe Brucker 提交于
      commit c5e2edeb01ae9ffbdde95bdcdb6d3614ba1eb195 upstream.
      
      GCC 8.1.0 reports that the ldadd instruction encoding, recently added to
      insn.c, doesn't match the mask and couldn't possibly be identified:
      
       linux/arch/arm64/include/asm/insn.h: In function 'aarch64_insn_is_ldadd':
       linux/arch/arm64/include/asm/insn.h:280:257: warning: bitwise comparison always evaluates to false [-Wtautological-compare]
      
      Bits [31:30] normally encode the size of the instruction (1 to 8 bytes)
      and the current instruction value only encodes the 4- and 8-byte
      variants. At the moment only the BPF JIT needs this instruction, and
      doesn't require the 1- and 2-byte variants, but to be consistent with
      our other ldr and str instruction encodings, clear the size field in the
      insn value.
      
      Fixes: 34b8ab091f9ef57a ("bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd")
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reported-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3919d91f
    • T
      usb: dwc3: Reset num_trbs after skipping · 9c423fd8
      Thinh Nguyen 提交于
      commit c7152763f02e05567da27462b2277a554e507c89 upstream.
      
      Currently req->num_trbs is not reset after the TRBs are skipped and
      processed from the cancelled list. The gadget driver may reuse the
      request with an invalid req->num_trbs, and DWC3 will incorrectly skip
      trbs. To fix this, simply reset req->num_trbs to 0 after skipping
      through all of them.
      
      Fixes: c3acd5901414 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()")
      Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c423fd8
    • X
      tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb · 2bbb6b54
      Xin Long 提交于
      commit c3bcde026684c62d7a2b6f626dc7cf763833875c upstream.
      
      udp_tunnel(6)_xmit_skb() called by tipc_udp_xmit() expects a tunnel device
      to count packets on dev->tstats, a perpcu variable. However, TIPC is using
      udp tunnel with no tunnel device, and pass the lower dev, like veth device
      that only initializes dev->lstats(a perpcu variable) when creating it.
      
      Later iptunnel_xmit_stats() called by ip(6)tunnel_xmit() thinks the dev as
      a tunnel device, and uses dev->tstats instead of dev->lstats. tstats' each
      pointer points to a bigger struct than lstats, so when tstats->tx_bytes is
      increased, other percpu variable's members could be overwritten.
      
      syzbot has reported quite a few crashes due to fib_nh_common percpu member
      'nhc_pcpu_rth_output' overwritten, call traces are like:
      
        BUG: KASAN: slab-out-of-bounds in rt_cache_valid+0x158/0x190
        net/ipv4/route.c:1556
          rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556
          __mkroute_output net/ipv4/route.c:2332 [inline]
          ip_route_output_key_hash_rcu+0x819/0x2d50 net/ipv4/route.c:2564
          ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393
          __ip_route_output_key include/net/route.h:125 [inline]
          ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651
          ip_route_output_key include/net/route.h:135 [inline]
        ...
      
      or:
      
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        RIP: 0010:dst_dev_put+0x24/0x290 net/core/dst.c:168
          <IRQ>
          rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:200 [inline]
          free_fib_info_rcu+0x2e1/0x490 net/ipv4/fib_semantics.c:217
          __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
          rcu_do_batch kernel/rcu/tree.c:2437 [inline]
          invoke_rcu_callbacks kernel/rcu/tree.c:2716 [inline]
          rcu_process_callbacks+0x100a/0x1ac0 kernel/rcu/tree.c:2697
        ...
      
      The issue exists since tunnel stats update is moved to iptunnel_xmit by
      Commit 039f5062 ("ip_tunnel: Move stats update to iptunnel_xmit()"),
      and here to fix it by passing a NULL tunnel dev to udp_tunnel(6)_xmit_skb
      so that the packets counting won't happen on dev->tstats.
      
      Reported-by: syzbot+9d4c12bfd45a58738d0a@syzkaller.appspotmail.com
      Reported-by: syzbot+a9e23ea2aa21044c2798@syzkaller.appspotmail.com
      Reported-by: syzbot+c4c4b2bb358bb936ad7e@syzkaller.appspotmail.com
      Reported-by: syzbot+0290d2290a607e035ba1@syzkaller.appspotmail.com
      Reported-by: syzbot+a43d8d4e7e8a7a9e149e@syzkaller.appspotmail.com
      Reported-by: syzbot+a47c5f4c6c00fc1ed16e@syzkaller.appspotmail.com
      Fixes: 039f5062 ("ip_tunnel: Move stats update to iptunnel_xmit()")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bbb6b54
    • J
      RDMA: Directly cast the sockaddr union to sockaddr · 89c49e7b
      Jason Gunthorpe 提交于
      commit 641114d2af312d39ca9bbc2369d18a5823da51c6 upstream.
      
      gcc 9 now does allocation size tracking and thinks that passing the member
      of a union and then accessing beyond that member's bounds is an overflow.
      
      Instead of using the union member, use the entire union with a cast to
      get to the sockaddr. gcc will now know that the memory extends the full
      size of the union.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89c49e7b
    • W
      futex: Update comments and docs about return values of arch futex code · a319c8ff
      Will Deacon 提交于
      commit 427503519739e779c0db8afe876c1b33f3ac60ae upstream.
      
      The architecture implementations of 'arch_futex_atomic_op_inuser()' and
      'futex_atomic_cmpxchg_inatomic()' are permitted to return only -EFAULT,
      -EAGAIN or -ENOSYS in the case of failure.
      
      Update the comments in the asm-generic/ implementation and also a stray
      reference in the robust futex documentation.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a319c8ff
    • D
      bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd · 4423a82c
      Daniel Borkmann 提交于
      commit 34b8ab091f9ef57a2bb3c8c8359a0a03a8abf2f9 upstream.
      
      Since ARMv8.1 supplement introduced LSE atomic instructions back in 2016,
      lets add support for STADD and use that in favor of LDXR / STXR loop for
      the XADD mapping if available. STADD is encoded as an alias for LDADD with
      XZR as the destination register, therefore add LDADD to the instruction
      encoder along with STADD as special case and use it in the JIT for CPUs
      that advertise LSE atomics in CPUID register. If immediate offset in the
      BPF XADD insn is 0, then use dst register directly instead of temporary
      one.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4423a82c
    • W
      arm64: futex: Avoid copying out uninitialised stack in failed cmpxchg() · 436869e0
      Will Deacon 提交于
      commit 8e4e0ac02b449297b86498ac24db5786ddd9f647 upstream.
      
      Returning an error code from futex_atomic_cmpxchg_inatomic() indicates
      that the caller should not make any use of *uval, and should instead act
      upon on the value of the error code. Although this is implemented
      correctly in our futex code, we needlessly copy uninitialised stack to
      *uval in the error case, which can easily be avoided.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      436869e0
    • M
      bpf: udp: ipv6: Avoid running reuseport's bpf_prog from __udp6_lib_err · ba6340a7
      Martin KaFai Lau 提交于
      commit 4ac30c4b3659efac031818c418beb51e630d512d upstream.
      
      __udp6_lib_err() may be called when handling icmpv6 message. For example,
      the icmpv6 toobig(type=2).  __udp6_lib_lookup() is then called
      which may call reuseport_select_sock().  reuseport_select_sock() will
      call into a bpf_prog (if there is one).
      
      reuseport_select_sock() is expecting the skb->data pointing to the
      transport header (udphdr in this case).  For example, run_bpf_filter()
      is pulling the transport header.
      
      However, in the __udp6_lib_err() path, the skb->data is pointing to the
      ipv6hdr instead of the udphdr.
      
      One option is to pull and push the ipv6hdr in __udp6_lib_err().
      Instead of doing this, this patch follows how the original
      commit 538950a1 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF")
      was done in IPv4, which has passed a NULL skb pointer to
      reuseport_select_sock().
      
      Fixes: 538950a1 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF")
      Cc: Craig Gallek <kraig@google.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Acked-by: NCraig Gallek <kraig@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba6340a7
    • M
      bpf: udp: Avoid calling reuseport's bpf_prog from udp_gro · 79c6a8c0
      Martin KaFai Lau 提交于
      commit 257a525fe2e49584842c504a92c27097407f778f upstream.
      
      When the commit a6024562 ("udp: Add GRO functions to UDP socket")
      added udp[46]_lib_lookup_skb to the udp_gro code path, it broke
      the reuseport_select_sock() assumption that skb->data is pointing
      to the transport header.
      
      This patch follows an earlier __udp6_lib_err() fix by
      passing a NULL skb to avoid calling the reuseport's bpf_prog.
      
      Fixes: a6024562 ("udp: Add GRO functions to UDP socket")
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79c6a8c0
    • D
      bpf: fix unconnected udp hooks · 613bc37f
      Daniel Borkmann 提交于
      commit 983695fa676568fc0fe5ddd995c7267aabc24632 upstream.
      
      Intention of cgroup bind/connect/sendmsg BPF hooks is to act transparently
      to applications as also stated in original motivation in 7828f20e ("Merge
      branch 'bpf-cgroup-bind-connect'"). When recently integrating the latter
      two hooks into Cilium to enable host based load-balancing with Kubernetes,
      I ran into the issue that pods couldn't start up as DNS got broken. Kubernetes
      typically sets up DNS as a service and is thus subject to load-balancing.
      
      Upon further debugging, it turns out that the cgroupv2 sendmsg BPF hooks API
      is currently insufficient and thus not usable as-is for standard applications
      shipped with most distros. To break down the issue we ran into with a simple
      example:
      
        # cat /etc/resolv.conf
        nameserver 147.75.207.207
        nameserver 147.75.207.208
      
      For the purpose of a simple test, we set up above IPs as service IPs and
      transparently redirect traffic to a different DNS backend server for that
      node:
      
        # cilium service list
        ID   Frontend            Backend
        1    147.75.207.207:53   1 => 8.8.8.8:53
        2    147.75.207.208:53   1 => 8.8.8.8:53
      
      The attached BPF program is basically selecting one of the backends if the
      service IP/port matches on the cgroup hook. DNS breaks here, because the
      hooks are not transparent enough to applications which have built-in msg_name
      address checks:
      
        # nslookup 1.1.1.1
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        [...]
        ;; connection timed out; no servers could be reached
      
        # dig 1.1.1.1
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        [...]
      
        ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
        ;; global options: +cmd
        ;; connection timed out; no servers could be reached
      
      For comparison, if none of the service IPs is used, and we tell nslookup
      to use 8.8.8.8 directly it works just fine, of course:
      
        # nslookup 1.1.1.1 8.8.8.8
        1.1.1.1.in-addr.arpa	name = one.one.one.one.
      
      In order to fix this and thus act more transparent to the application,
      this needs reverse translation on recvmsg() side. A minimal fix for this
      API is to add similar recvmsg() hooks behind the BPF cgroups static key
      such that the program can track state and replace the current sockaddr_in{,6}
      with the original service IP. From BPF side, this basically tracks the
      service tuple plus socket cookie in an LRU map where the reverse NAT can
      then be retrieved via map value as one example. Side-note: the BPF cgroups
      static key should be converted to a per-hook static key in future.
      
      Same example after this fix:
      
        # cilium service list
        ID   Frontend            Backend
        1    147.75.207.207:53   1 => 8.8.8.8:53
        2    147.75.207.208:53   1 => 8.8.8.8:53
      
      Lookups work fine now:
      
        # nslookup 1.1.1.1
        1.1.1.1.in-addr.arpa    name = one.one.one.one.
      
        Authoritative answers can be found from:
      
        # dig 1.1.1.1
      
        ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51550
        ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
      
        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 512
        ;; QUESTION SECTION:
        ;1.1.1.1.                       IN      A
      
        ;; AUTHORITY SECTION:
        .                       23426   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2019052001 1800 900 604800 86400
      
        ;; Query time: 17 msec
        ;; SERVER: 147.75.207.207#53(147.75.207.207)
        ;; WHEN: Tue May 21 12:59:38 UTC 2019
        ;; MSG SIZE  rcvd: 111
      
      And from an actual packet level it shows that we're using the back end
      server when talking via 147.75.207.20{7,8} front end:
      
        # tcpdump -i any udp
        [...]
        12:59:52.698732 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
        12:59:52.698735 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
        12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
        12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
        [...]
      
      In order to be flexible and to have same semantics as in sendmsg BPF
      programs, we only allow return codes in [1,1] range. In the sendmsg case
      the program is called if msg->msg_name is present which can be the case
      in both, connected and unconnected UDP.
      
      The former only relies on the sockaddr_in{,6} passed via connect(2) if
      passed msg->msg_name was NULL. Therefore, on recvmsg side, we act in similar
      way to call into the BPF program whenever a non-NULL msg->msg_name was
      passed independent of sk->sk_state being TCP_ESTABLISHED or not. Note
      that for TCP case, the msg->msg_name is ignored in the regular recvmsg
      path and therefore not relevant.
      
      For the case of ip{,v6}_recv_error() paths, picked up via MSG_ERRQUEUE,
      the hook is not called. This is intentional as it aligns with the same
      semantics as in case of TCP cgroup BPF hooks right now. This might be
      better addressed in future through a different bpf_attach_type such
      that this case can be distinguished from the regular recvmsg paths,
      for example.
      
      Fixes: 1cedee13 ("bpf: Hooks for sys_sendmsg")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NMartynas Pumputis <m@lambda.lt>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      613bc37f
    • M
      bpf: fix nested bpf tracepoints with per-cpu data · a7177b94
      Matt Mullins 提交于
      commit 9594dc3c7e71b9f52bee1d7852eb3d4e3aea9e99 upstream.
      
      BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
      they do not increment bpf_prog_active while executing.
      
      This enables three levels of nesting, to support
        - a kprobe or raw tp or perf event,
        - another one of the above that irq context happens to call, and
        - another one in nmi context
      (at most one of which may be a kprobe or perf event).
      
      Fixes: 20b9d7ac ("bpf: avoid excessive stack usage for perf_sample_data")
      Signed-off-by: NMatt Mullins <mmullins@fb.com>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7177b94
    • J
      bpf: lpm_trie: check left child of last leftmost node for NULL · 4992d4af
      Jonathan Lemon 提交于
      commit da2577fdd0932ea4eefe73903f1130ee366767d2 upstream.
      
      If the leftmost parent node of the tree has does not have a child
      on the left side, then trie_get_next_key (and bpftool map dump) will
      not look at the child on the right.  This leads to the traversal
      missing elements.
      
      Lookup is not affected.
      
      Update selftest to handle this case.
      
      Reproducer:
      
       bpftool map create /sys/fs/bpf/lpm type lpm_trie key 6 \
           value 1 entries 256 name test_lpm flags 1
       bpftool map update pinned /sys/fs/bpf/lpm key  8 0 0 0  0   0 value 1
       bpftool map update pinned /sys/fs/bpf/lpm key 16 0 0 0  0 128 value 2
       bpftool map dump   pinned /sys/fs/bpf/lpm
      
      Returns only 1 element. (2 expected)
      
      Fixes: b471f2f1 ("bpf: implement MAP_GET_NEXT_KEY command for LPM_TRIE")
      Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4992d4af
    • M
      bpf: simplify definition of BPF_FIB_LOOKUP related flags · 5e558f9a
      Martynas Pumputis 提交于
      commit b1d6c15b9d824a58c5415673f374fac19e8eccdf upstream.
      
      Previously, the BPF_FIB_LOOKUP_{DIRECT,OUTPUT} flags in the BPF UAPI
      were defined with the help of BIT macro. This had the following issues:
      
      - In order to use any of the flags, a user was required to depend
        on <linux/bits.h>.
      - No other flag in bpf.h uses the macro, so it seems that an unwritten
        convention is to use (1 << (nr)) to define BPF-related flags.
      
      Fixes: 87f5fc7e ("bpf: Provide helper to do forwarding lookups in kernel FIB table")
      Signed-off-by: NMartynas Pumputis <m@lambda.lt>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e558f9a
    • F
      tun: wake up waitqueues after IFF_UP is set · 7d2c0ec2
      Fei Li 提交于
      [ Upstream commit 72b319dc08b4924a29f5e2560ef6d966fa54c429 ]
      
      Currently after setting tap0 link up, the tun code wakes tx/rx waited
      queues up in tun_net_open() when .ndo_open() is called, however the
      IFF_UP flag has not been set yet. If there's already a wait queue, it
      would fail to transmit when checking the IFF_UP flag in tun_sendmsg().
      Then the saving vhost_poll_start() will add the wq into wqh until it
      is waken up again. Although this works when IFF_UP flag has been set
      when tun_chr_poll detects; this is not true if IFF_UP flag has not
      been set at that time. Sadly the latter case is a fatal error, as
      the wq will never be waken up in future unless later manually
      setting link up on purpose.
      
      Fix this by moving the wakeup process into the NETDEV_UP event
      notifying process, this makes sure IFF_UP has been set before all
      waited queues been waken up.
      Signed-off-by: NFei Li <lifei.shirley@bytedance.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d2c0ec2
    • X
      tipc: check msg->req data len in tipc_nl_compat_bearer_disable · a08b9154
      Xin Long 提交于
      [ Upstream commit 4f07b80c973348a99b5d2a32476a2e7877e94a05 ]
      
      This patch is to fix an uninit-value issue, reported by syzbot:
      
        BUG: KMSAN: uninit-value in memchr+0xce/0x110 lib/string.c:981
        Call Trace:
          __dump_stack lib/dump_stack.c:77 [inline]
          dump_stack+0x191/0x1f0 lib/dump_stack.c:113
          kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
          __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
          memchr+0xce/0x110 lib/string.c:981
          string_is_valid net/tipc/netlink_compat.c:176 [inline]
          tipc_nl_compat_bearer_disable+0x2a1/0x480 net/tipc/netlink_compat.c:449
          __tipc_nl_compat_doit net/tipc/netlink_compat.c:327 [inline]
          tipc_nl_compat_doit+0x3ac/0xb00 net/tipc/netlink_compat.c:360
          tipc_nl_compat_handle net/tipc/netlink_compat.c:1178 [inline]
          tipc_nl_compat_recv+0x1b1b/0x27b0 net/tipc/netlink_compat.c:1281
      
      TLV_GET_DATA_LEN() may return a negtive int value, which will be
      used as size_t (becoming a big unsigned long) passed into memchr,
      cause this issue.
      
      Similar to what it does in tipc_nl_compat_bearer_enable(), this
      fix is to return -EINVAL when TLV_GET_DATA_LEN() is negtive in
      tipc_nl_compat_bearer_disable(), as well as in
      tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
      
      v1->v2:
        - add the missing Fixes tags per Eric's request.
      
      Fixes: 0762216c0ad2 ("tipc: fix uninit-value in tipc_nl_compat_bearer_enable")
      Fixes: 8b66fee7f8ee ("tipc: fix uninit-value in tipc_nl_compat_link_reset_stats")
      Reported-by: syzbot+30eaa8bf392f7fafffaf@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a08b9154
    • X
      tipc: change to use register_pernet_device · fdf3e98e
      Xin Long 提交于
      [ Upstream commit c492d4c74dd3f87559883ffa0f94a8f1ae3fe5f5 ]
      
      This patch is to fix a dst defcnt leak, which can be reproduced by doing:
      
        # ip net a c; ip net a s; modprobe tipc
        # ip net e s ip l a n eth1 type veth peer n eth1 netns c
        # ip net e c ip l s lo up; ip net e c ip l s eth1 up
        # ip net e s ip l s lo up; ip net e s ip l s eth1 up
        # ip net e c ip a a 1.1.1.2/8 dev eth1
        # ip net e s ip a a 1.1.1.1/8 dev eth1
        # ip net e c tipc b e m udp n u1 localip 1.1.1.2
        # ip net e s tipc b e m udp n u1 localip 1.1.1.1
        # ip net d c; ip net d s; rmmod tipc
      
      and it will get stuck and keep logging the error:
      
        unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx
      path with udp_early_demux == 1, and this dst (eventually holding lo dev)
      can't be released as bearer's removal in tipc pernet .exit happens after
      lo dev's removal, default_device pernet .exit.
      
       "There are two distinct types of pernet_operations recognized: subsys and
        device.  At creation all subsys init functions are called before device
        init functions, and at destruction all device exit functions are called
        before subsys exit function."
      
      So by calling register_pernet_device instead to register tipc_net_ops, the
      pernet .exit() will be invoked earlier than loopback dev's removal when a
      netns is being destroyed, as fou/gue does.
      
      Note that vxlan and geneve udp tunnels don't have this issue, as the udp
      sock is released in their device ndo_stop().
      
      This fix is also necessary for tipc dst_cache, which will hold dsts on tx
      path and I will introduce in my next patch.
      Reported-by: NLi Shuang <shuali@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdf3e98e
    • Y
      team: Always enable vlan tx offload · 32b711f5
      YueHaibing 提交于
      [ Upstream commit ee4297420d56a0033a8593e80b33fcc93fda8509 ]
      
      We should rather have vlan_tci filled all the way down
      to the transmitting netdevice and let it do the hw/sw
      vlan implementation.
      Suggested-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32b711f5
    • X
      sctp: change to hold sk after auth shkey is created successfully · eeb770d6
      Xin Long 提交于
      [ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
      
      Now in sctp_endpoint_init(), it holds the sk then creates auth
      shkey. But when the creation fails, it doesn't release the sk,
      which causes a sk defcnf leak,
      
      Here to fix it by only holding the sk when auth shkey is created
      successfully.
      
      Fixes: a29a5bd4 ("[SCTP]: Implement SCTP-AUTH initializations.")
      Reported-by: syzbot+afabda3890cc2f765041@syzkaller.appspotmail.com
      Reported-by: syzbot+276ca1c77a19977c0130@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eeb770d6
    • R
      net: stmmac: set IC bit when transmitting frames with HW timestamp · 9b7b0aab
      Roland Hii 提交于
      [ Upstream commit d0bb82fd60183868f46c8ccc595a3d61c3334a18 ]
      
      When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the
      PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit
      hardware timestamp. The polling will most likely timeout if the tx
      coalesce is enabled due to the Interrupt-on-Completion (IC) bit is
      not set in tx descriptor for those frames.
      
      This patch will ignore the tx coalesce parameter and set the IC bit
      when transmitting PTP frames which need to report out the frame
      transmit hardware timestamp to user space.
      
      Fixes: f748be53 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
      Signed-off-by: NRoland Hii <roland.king.guan.hii@intel.com>
      Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NVoon Weifeng <weifeng.voon@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b7b0aab
    • R
      net: stmmac: fixed new system time seconds value calculation · a373bf72
      Roland Hii 提交于
      [ Upstream commit a1e5388b4d5fc78688e5e9ee6641f779721d6291 ]
      
      When ADDSUB bit is set, the system time seconds field is calculated as
      the complement of the seconds part of the update value.
      
      For example, if 3.000000001 seconds need to be subtracted from the
      system time, this field is calculated as
      2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD
      
      Previously, the 0x100000000 is mistakenly written as 100000000.
      
      This is further simplified from
        sec = (0x100000000ULL - sec);
      to
        sec = -sec;
      
      Fixes: ba1ffd74 ("stmmac: fix PTP support for GMAC4")
      Signed-off-by: NRoland Hii <roland.king.guan.hii@intel.com>
      Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NVoon Weifeng <weifeng.voon@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a373bf72
    • J
      net: remove duplicate fetch in sock_getsockopt · 7d76fc21
      JingYi Hou 提交于
      [ Upstream commit d0bae4a0e3d8c5690a885204d7eb2341a5b4884d ]
      
      In sock_getsockopt(), 'optlen' is fetched the first time from userspace.
      'len < 0' is then checked. Then in condition 'SO_MEMINFO', 'optlen' is
      fetched the second time from userspace.
      
      If change it between two fetches may cause security problems or unexpected
      behaivor, and there is no reason to fetch it a second time.
      
      To fix this, we need to remove the second fetch.
      Signed-off-by: NJingYi Hou <houjingyi647@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d76fc21
    • E
      net/packet: fix memory leak in packet_set_ring() · 05dceb60
      Eric Dumazet 提交于
      [ Upstream commit 55655e3d1197fff16a7a05088fb0e5eba50eac55 ]
      
      syzbot found we can leak memory in packet_set_ring(), if user application
      provides buggy parameters.
      
      Fixes: 7f953ab2 ("af_packet: TX_RING support for TPACKET_V3")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Sowmini Varadhan <sowmini.varadhan@oracle.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05dceb60