1. 10 9月, 2019 18 次提交
    • M
      Bluetooth: btqca: Add a short delay before downloading the NVM · 32e912b9
      Matthias Kaehlcke 提交于
      [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]
      
      On WCN3990 downloading the NVM sometimes fails with a "TLV response
      size mismatch" error:
      
      [  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
      [  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch
      
      It seems the controller needs a short time after downloading the
      firmware before it is ready for the NVM. A delay as short as 1 ms
      seems sufficient, make it 10 ms just in case. No event is received
      during the delay, hence we don't just silently drop an extra event.
      Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      32e912b9
    • N
      net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx · 7b7a1154
      Nathan Chancellor 提交于
      [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]
      
      clang warns:
      
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
      '&&' with constant operand [-Wconstant-logical-operand]
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                        ^  ~~~~~~~~~~~~
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
      bitwise operation
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                        ^~
                                                        &
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
      silence this warning
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                       ~^~~~~~~~~~~~~~~
      1 warning generated.
      
      Explicitly check that NET_IP_ALIGN is not zero, which matches how this
      is checked in other parts of the tree. Because NET_IP_ALIGN is a build
      time constant, this check will be constant folded away during
      optimization.
      
      Fixes: 82a9928d ("tc35815: Enable StripCRC feature")
      Link: https://github.com/ClangBuiltLinux/linux/issues/608Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7b7a1154
    • D
      hv_netvsc: Fix a warning of suspicious RCU usage · 752832f2
      Dexuan Cui 提交于
      [ Upstream commit 6d0d779dca73cd5acb649c54f81401f93098b298 ]
      
      This fixes a warning of "suspicious rcu_dereference_check() usage"
      when nload runs.
      
      Fixes: 776e726b ("netvsc: fix RCU warning in get_stats")
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      752832f2
    • J
      tools: bpftool: fix error message (prog -> object) · 463d87bc
      Jakub Kicinski 提交于
      [ Upstream commit b3e78adcbf991a4e8b2ebb23c9889e968ec76c5f ]
      
      Change an error message to work for any object being
      pinned not just programs.
      
      Fixes: 71bb428f ("tools: bpf: add bpftool")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      463d87bc
    • P
      netfilter: nf_tables: use-after-free in failing rule with bound set · 5776970f
      Pablo Neira Ayuso 提交于
      [ Upstream commit 6a0a8d10a3661a036b55af695542a714c429ab7c ]
      
      If a rule that has already a bound anonymous set fails to be added, the
      preparation phase releases the rule and the bound set. However, the
      transaction object from the abort path still has a reference to the set
      object that is stale, leading to a use-after-free when checking for the
      set->bound field. Add a new field to the transaction that specifies if
      the set is bound, so the abort path can skip releasing it since the rule
      command owns it and it takes care of releasing it. After this update,
      the set->bound field is removed.
      
      [   24.649883] Unable to handle kernel paging request at virtual address 0000000000040434
      [   24.657858] Mem abort info:
      [   24.660686]   ESR = 0x96000004
      [   24.663769]   Exception class = DABT (current EL), IL = 32 bits
      [   24.669725]   SET = 0, FnV = 0
      [   24.672804]   EA = 0, S1PTW = 0
      [   24.675975] Data abort info:
      [   24.678880]   ISV = 0, ISS = 0x00000004
      [   24.682743]   CM = 0, WnR = 0
      [   24.685723] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000428952000
      [   24.692207] [0000000000040434] pgd=0000000000000000
      [   24.697119] Internal error: Oops: 96000004 [#1] SMP
      [...]
      [   24.889414] Call trace:
      [   24.891870]  __nf_tables_abort+0x3f0/0x7a0
      [   24.895984]  nf_tables_abort+0x20/0x40
      [   24.899750]  nfnetlink_rcv_batch+0x17c/0x588
      [   24.904037]  nfnetlink_rcv+0x13c/0x190
      [   24.907803]  netlink_unicast+0x18c/0x208
      [   24.911742]  netlink_sendmsg+0x1b0/0x350
      [   24.915682]  sock_sendmsg+0x4c/0x68
      [   24.919185]  ___sys_sendmsg+0x288/0x2c8
      [   24.923037]  __sys_sendmsg+0x7c/0xd0
      [   24.926628]  __arm64_sys_sendmsg+0x2c/0x38
      [   24.930744]  el0_svc_common.constprop.0+0x94/0x158
      [   24.935556]  el0_svc_handler+0x34/0x90
      [   24.939322]  el0_svc+0x8/0xc
      [   24.942216] Code: 37280300 f9404023 91014262 aa1703e0 (f9401863)
      [   24.948336] ---[ end trace cebbb9dcbed3b56f ]---
      
      Fixes: f6ac85858976 ("netfilter: nf_tables: unbind set in rule from commit path")
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5776970f
    • F
      net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context · d22ed7b7
      Fuqian Huang 提交于
      [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]
      
      As spin_unlock_irq will enable interrupts.
      Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
      Interrupts are enabled in interrupt handler.
      Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
      in IRQ context to avoid this.
      Signed-off-by: NFuqian Huang <huangfq.daxian@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d22ed7b7
    • M
      spi: bcm2835aux: fix corruptions for longer spi transfers · 3ddda4f3
      Martin Sperl 提交于
      [ Upstream commit 73b114ee7db1750c0b535199fae383b109bd61d0 ]
      
      On long running tests with a mcp2517fd can controller it showed that
      on rare occations the data read shows corruptions for longer spi transfers.
      
      Example of a 22 byte transfer:
      
      expected (as captured on logic analyzer):
      FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 85 86 87 88 89 8a 8b
      
      read by the driver:
      FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 88 89 8a 00 00 8b 9b
      
      To fix this use BCM2835_AUX_SPI_STAT_RX_LVL to determine when we may
      read data from the fifo reliably without any corruption.
      
      Surprisingly the only values ever empirically read in
      BCM2835_AUX_SPI_STAT_RX_LVL are 0x00, 0x10, 0x20 and 0x30.
      So whenever the mask is not 0 we can read from the fifo in a safe manner.
      
      The patch has now been tested intensively and we are no longer
      able to reproduce the "RX" issue any longer.
      
      Fixes: 1ea29b39 ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
      Reported-by: NHubert Denkmair <h.denkmair@intence.de>
      Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
      Acked-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3ddda4f3
    • M
      spi: bcm2835aux: remove dangerous uncontrolled read of fifo · fe49c3de
      Martin Sperl 提交于
      [ Upstream commit c7de8500fd8ecbb544846dd5f11dca578c3777e1 ]
      
      This read of the fifo is a potential candidate for a race condition
      as the spi transfer is not necessarily finished and so can lead to
      an early read of the fifo that still misses data.
      
      So it has been removed.
      
      Fixes: 1ea29b39 ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
      Suggested-by: NHubert Denkmair <h.denkmair@intence.de>
      Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
      Acked-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fe49c3de
    • M
      spi: bcm2835aux: unifying code between polling and interrupt driven code · a4a9ee79
      Martin Sperl 提交于
      [ Upstream commit 7188a6f0eee3f1fae5d826cfc6d569657ff950ec ]
      
      Sharing more code between polling and interrupt-driven mode.
      Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
      Acked-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a4a9ee79
    • J
      x86/boot: Preserve boot_params.secure_boot from sanitizing · ee271ead
      John S. Gruber 提交于
      commit 29d9a0b50736768f042752070e5cdf4e4d4c00df upstream.
      
      Commit
      
        a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else")
      
      now zeroes the secure boot setting information (enabled/disabled/...)
      passed by the boot loader or by the kernel's EFI handover mechanism.
      
      The problem manifests itself with signed kernels using the EFI handoff
      protocol with grub and the kernel loses the information whether secure
      boot is enabled in the firmware, i.e., the log message "Secure boot
      enabled" becomes "Secure boot could not be determined".
      
      efi_main() arch/x86/boot/compressed/eboot.c sets this field early but it
      is subsequently zeroed by the above referenced commit.
      
      Include boot_params.secure_boot in the preserve field list.
      
       [ bp: restructure commit message and massage. ]
      
      Fixes: a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else")
      Signed-off-by: NJohn S. Gruber <JohnSGruber@gmail.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NJohn Hubbard <jhubbard@nvidia.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: stable <stable@vger.kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/CAPotdmSPExAuQcy9iAHqX3js_fc4mMLQOTr5RBGvizyCOPcTQQ@mail.gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee271ead
    • K
      net/rds: Fix info leak in rds6_inc_info_copy() · 9484203d
      Ka-Cheong Poon 提交于
      [ Upstream commit 7d0a06586b2686ba80c4a2da5f91cb10ffbea736 ]
      
      The rds6_inc_info_copy() function has a couple struct members which
      are leaking stack information.  The ->tos field should hold actual
      information and the ->flags field needs to be zeroed out.
      
      Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure")
      Fixes: b7ff8b10 ("rds: Extend RDS API for IPv6 support")
      Reported-by: N黄ID蝴蝶 <butterflyhuangxx@gmail.com>
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9484203d
    • E
      tcp: remove empty skb from write queue in error cases · 5977bc19
      Eric Dumazet 提交于
      [ Upstream commit fdfc5c8594c24c5df883583ebd286321a80e0a67 ]
      
      Vladimir Rutsky reported stuck TCP sessions after memory pressure
      events. Edge Trigger epoll() user would never receive an EPOLLOUT
      notification allowing them to retry a sendmsg().
      
      Jason tested the case of sk_stream_alloc_skb() returning NULL,
      but there are other paths that could lead both sendmsg() and sendpage()
      to return -1 (EAGAIN), with an empty skb queued on the write queue.
      
      This patch makes sure we remove this empty skb so that
      Jason code can detect that the queue is empty, and
      call sk->sk_write_space(sk) accordingly.
      
      Fixes: ce5ec440 ("tcp: ensure epoll edge trigger wakeup when write queue is empty")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jason Baron <jbaron@akamai.com>
      Reported-by: NVladimir Rutsky <rutsky@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5977bc19
    • W
      tcp: inherit timestamp on mtu probe · 6f312637
      Willem de Bruijn 提交于
      [ Upstream commit 888a5c53c0d8be6e98bc85b677f179f77a647873 ]
      
      TCP associates tx timestamp requests with a byte in the bytestream.
      If merging skbs in tcp_mtu_probe, migrate the tstamp request.
      
      Similar to MSG_EOR, do not allow moving a timestamp from any segment
      in the probe but the last. This to avoid merging multiple timestamps.
      
      Tested with the packetdrill script at
      https://github.com/wdebruij/packetdrill/commits/mtu_probe-1
      
      Link: http://patchwork.ozlabs.org/patch/1143278/#2232897
      Fixes: 4ed2d765 ("net-timestamp: TCP timestamping")
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f312637
    • C
      net: stmmac: dwmac-rk: Don't fail if phy regulator is absent · 6f8348f6
      Chen-Yu Tsai 提交于
      [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]
      
      The devicetree binding lists the phy phy as optional. As such, the
      driver should not bail out if it can't find a regulator. Instead it
      should just skip the remaining regulator related code and continue
      on normally.
      
      Skip the remainder of phy_power_on() if a regulator supply isn't
      available. This also gets rid of the bogus return code.
      
      Fixes: 2e12f536 ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f8348f6
    • C
      net_sched: fix a NULL pointer deref in ipt action · 38166934
      Cong Wang 提交于
      [ Upstream commit 981471bd3abf4d572097645d765391533aac327d ]
      
      The net pointer in struct xt_tgdtor_param is not explicitly
      initialized therefore is still NULL when dereferencing it.
      So we have to find a way to pass the correct net pointer to
      ipt_destroy_target().
      
      The best way I find is just saving the net pointer inside the per
      netns struct tcf_idrinfo, which could make this patch smaller.
      
      Fixes: 0c66dc1e ("netfilter: conntrack: register hooks in netns when needed by ruleset")
      Reported-and-tested-by: itugrok@yahoo.com
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38166934
    • V
      net: sched: act_sample: fix psample group handling on overwrite · 5ff0ab0c
      Vlad Buslov 提交于
      [ Upstream commit dbf47a2a094edf58983265e323ca4bdcdb58b5ee ]
      
      Action sample doesn't properly handle psample_group pointer in overwrite
      case. Following issues need to be fixed:
      
      - In tcf_sample_init() function RCU_INIT_POINTER() is used to set
        s->psample_group, even though we neither setting the pointer to NULL, nor
        preventing concurrent readers from accessing the pointer in some way.
        Use rcu_swap_protected() instead to safely reset the pointer.
      
      - Old value of s->psample_group is not released or deallocated in any way,
        which results resource leak. Use psample_group_put() on non-NULL value
        obtained with rcu_swap_protected().
      
      - The function psample_group_put() that released reference to struct
        psample_group pointed by rcu-pointer s->psample_group doesn't respect rcu
        grace period when deallocating it. Extend struct psample_group with rcu
        head and use kfree_rcu when freeing it.
      
      Fixes: 5c5670fa ("net/sched: Introduce sample tc action")
      Signed-off-by: NVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ff0ab0c
    • F
      net: fix skb use after free in netpoll · 6a2bd826
      Feng Sun 提交于
      [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ]
      
      After commit baeababb
      ("tun: return NET_XMIT_DROP for dropped packets"),
      when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
      netpoll_send_skb_on_dev will run into following use after free cases:
      1. retry netpoll_start_xmit with freed skb;
      2. queue freed skb in npinfo->txq.
      queue_process will also run into use after free case.
      
      hit netpoll_send_skb_on_dev first case with following kernel log:
      
      [  117.864773] kernel BUG at mm/slub.c:306!
      [  117.864773] invalid opcode: 0000 [#1] SMP PTI
      [  117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P           OE     5.3.0-050300rc5-generic #201908182231
      [  117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
      [  117.864781] Call Trace:
      [  117.864781]  ? tun_net_xmit+0x21c/0x460
      [  117.864781]  kfree_skbmem+0x4e/0x60
      [  117.864782]  kfree_skb+0x3a/0xa0
      [  117.864782]  tun_net_xmit+0x21c/0x460
      [  117.864782]  netpoll_start_xmit+0x11d/0x1b0
      [  117.864788]  netpoll_send_skb_on_dev+0x1b8/0x200
      [  117.864789]  __br_forward+0x1b9/0x1e0 [bridge]
      [  117.864789]  ? skb_clone+0x53/0xd0
      [  117.864790]  ? __skb_clone+0x2e/0x120
      [  117.864790]  deliver_clone+0x37/0x50 [bridge]
      [  117.864790]  maybe_deliver+0x89/0xc0 [bridge]
      [  117.864791]  br_flood+0x6c/0x130 [bridge]
      [  117.864791]  br_dev_xmit+0x315/0x3c0 [bridge]
      [  117.864792]  netpoll_start_xmit+0x11d/0x1b0
      [  117.864792]  netpoll_send_skb_on_dev+0x1b8/0x200
      [  117.864792]  netpoll_send_udp+0x2c6/0x3e8
      [  117.864793]  write_msg+0xd9/0xf0 [netconsole]
      [  117.864793]  console_unlock+0x386/0x4e0
      [  117.864793]  vprintk_emit+0x17e/0x280
      [  117.864794]  vprintk_default+0x29/0x50
      [  117.864794]  vprintk_func+0x4c/0xbc
      [  117.864794]  printk+0x58/0x6f
      [  117.864795]  loop_fun+0x24/0x41 [printmsg_loop]
      [  117.864795]  kthread+0x104/0x140
      [  117.864795]  ? 0xffffffffc05b1000
      [  117.864796]  ? kthread_park+0x80/0x80
      [  117.864796]  ret_from_fork+0x35/0x40
      Signed-off-by: NFeng Sun <loyou85@gmail.com>
      Signed-off-by: NXiaojun Zhao <xiaojunzhao141@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a2bd826
    • E
      mld: fix memory leak in mld_del_delrec() · 8a5d27ea
      Eric Dumazet 提交于
      [ Upstream commit a84d016479896b5526a2cc54784e6ffc41c9d6f6 ]
      
      Similar to the fix done for IPv4 in commit e5b1c6c6277d
      ("igmp: fix memory leak in igmpv3_del_delrec()"), we need to
      make sure mca_tomb and mca_sources are not blindly overwritten.
      
      Using swap() then a call to ip6_mc_clear_src() will take care
      of the missing free.
      
      BUG: memory leak
      unreferenced object 0xffff888117d9db00 (size 64):
        comm "syz-executor247", pid 6918, jiffies 4294943989 (age 25.350s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 fe 88 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000005b463030>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
          [<000000005b463030>] slab_post_alloc_hook mm/slab.h:522 [inline]
          [<000000005b463030>] slab_alloc mm/slab.c:3319 [inline]
          [<000000005b463030>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
          [<00000000939cbf94>] kmalloc include/linux/slab.h:552 [inline]
          [<00000000939cbf94>] kzalloc include/linux/slab.h:748 [inline]
          [<00000000939cbf94>] ip6_mc_add1_src net/ipv6/mcast.c:2236 [inline]
          [<00000000939cbf94>] ip6_mc_add_src+0x31f/0x420 net/ipv6/mcast.c:2356
          [<00000000d8972221>] ip6_mc_source+0x4a8/0x600 net/ipv6/mcast.c:449
          [<000000002b203d0d>] do_ipv6_setsockopt.isra.0+0x1b92/0x1dd0 net/ipv6/ipv6_sockglue.c:748
          [<000000001f1e2d54>] ipv6_setsockopt+0x89/0xd0 net/ipv6/ipv6_sockglue.c:944
          [<00000000c8f7bdf9>] udpv6_setsockopt+0x4e/0x90 net/ipv6/udp.c:1558
          [<000000005a9a0c5e>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3139
          [<00000000910b37b2>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
          [<00000000e9108023>] __do_sys_setsockopt net/socket.c:2100 [inline]
          [<00000000e9108023>] __se_sys_setsockopt net/socket.c:2097 [inline]
          [<00000000e9108023>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
          [<00000000f4818160>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
          [<000000008d367e8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1666d49e ("mld: do not remove mld souce list info when set link down")
      Fixes: 9c8bb163 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
      Signed-off-by: NEric Dumazet <edumazet@google.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>
      8a5d27ea
  2. 06 9月, 2019 22 次提交
    • G
      Linux 4.19.71 · e7d2672c
      Greg Kroah-Hartman 提交于
      e7d2672c
    • B
      Revert "Input: elantech - enable SMBus on new (2018+) systems" · 72168ae7
      Benjamin Tissoires 提交于
      This reverts commit 3d180fe5 which is
      commit 883a2a80f79ca5c0c105605fafabd1f3df99b34c upstream.
      
      This patch depends on an other series:
      https://patchwork.kernel.org/project/linux-input/list/?series=122327&state=%2A&archive=both
      
      It was a mistake to backport it in the v5.2 branch, as there
      is a high chance we encounter a touchpad that needs the series
      above.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=204733
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=204771Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72168ae7
    • G
      Linux 4.19.70 · 0fed55c2
      Greg Kroah-Hartman 提交于
      0fed55c2
    • G
      Revert "ASoC: Fail card instantiation if DAI format setup fails" · 9854d089
      Greg Kroah-Hartman 提交于
      This reverts commit 714a8438 which is
      commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b upstream.
      
      Mark Brown writes:
      	I nacked this patch when Sasha posted it - it only improves
      	diagnostics and might make systems that worked by accident break
      	since it turns things into a hard failure, it won't make
      	anything that didn't work previously work.
      Reported-by: NMark Brown <broonie@kernel.org>
      Cc: Ricard Wanderlof <ricardw@axis.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Link: https://lore.kernel.org/lkml/20190904181027.GG4348@sirena.co.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9854d089
    • S
      mt76: mt76x0u: do not reset radio on resume · e064466c
      Stanislaw Gruszka 提交于
      commit 8f2d163cb26da87e7d8e1677368b8ba1ba4d30b3 upstream.
      
      On some machines mt76x0u firmware can hung during resume,
      what result on messages like below:
      
      [  475.480062] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  475.990066] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
      [  475.990075] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  476.500003] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
      [  476.500012] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  477.010046] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
      [  477.010055] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  477.529997] mt76x0 1-8:1.0: Error: send MCU cmd failed:-110
      [  477.530006] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  477.824907] mt76x0 1-8:1.0: Error: send MCU cmd failed:-71
      [  477.824916] mt76x0 1-8:1.0: Error: MCU response pre-completed!
      [  477.825029] usb 1-8: USB disconnect, device number 6
      
      and possible whole system freeze.
      
      This can be avoided, if we do not perform mt76x0_chip_onoff() reset.
      
      Cc: stable@vger.kernel.org
      Fixes: 134b2d0d ("mt76x0: init files")
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e064466c
    • G
      x86/ptrace: fix up botched merge of spectrev1 fix · b307f99d
      Greg Kroah-Hartman 提交于
      I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
      spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
      graciously pointed out at
      https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php
      
      Resolve the upstream difference with the stable kernel merge to properly
      protect things.
      Reported-by: NBrad Spengler <spender@grsecurity.net>
      Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <bp@alien8.de>
      Cc: <hpa@zytor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b307f99d
    • A
      i2c: piix4: Fix port selection for AMD Family 16h Model 30h · 3b26fa9e
      Andrew Cooks 提交于
      [ Upstream commit c7c06a1532f3fe106687ac82a13492c6a619ff1c ]
      
      Family 16h Model 30h SMBus controller needs the same port selection fix
      as described and fixed in commit 0fe16195 ("i2c: piix4: Fix SMBus port
      selection for AMD Family 17h chips")
      
      commit 6befa3fd ("i2c: piix4: Support alternative port selection
      register") also fixed the port selection for Hudson2, but unfortunately
      this is not the exact same device and the AMD naming and PCI Device IDs
      aren't particularly helpful here.
      
      The SMBus port selection register is common to the following Families
      and models, as documented in AMD's publicly available BIOS and Kernel
      Developer Guides:
      
       50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
       55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
       52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS)
      
      The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared
      between Bolton FCH and Family 16h Model 30h, but the location of the
      SmBus0Sel port selection bits are different:
      
       51192 - Bolton Register Reference Guide
      
      We distinguish between Bolton and Family 16h Model 30h using the PCI
      Revision ID:
      
        Bolton is device 0x780b, revision 0x15
        Family 16h Model 30h is device 0x780b, revision 0x1F
        Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A.
      
      The following additional public AMD BKDG documents were checked and do
      not share the same port selection register:
      
       42301 - Family 15h Model 00h-0Fh doesn't mention any
       42300 - Family 15h Model 10h-1Fh doesn't mention any
       49125 - Family 15h Model 30h-3Fh doesn't mention any
      
       48751 - Family 16h Model 00h-0Fh uses the previously supported
               index register SB800_PIIX4_PORT_IDX_ALT at 0x2e
      Signed-off-by: NAndrew Cooks <andrew.cooks@opengear.com>
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: stable@vger.kernel.org [v4.6+]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b26fa9e
    • T
      NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0 · 4f4be79c
      Trond Myklebust 提交于
      [ Upstream commit eb2c50da9e256dbbb3ff27694440e4c1900cfef8 ]
      
      If the attempt to resend the I/O results in no bytes being read/written,
      we must ensure that we report the error.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Fixes: 0a00b77b ("nfs: mirroring support for direct io")
      Cc: stable@vger.kernel.org # v3.20+
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4f4be79c
    • T
      NFS: Pass error information to the pgio error cleanup routine · b5891b62
      Trond Myklebust 提交于
      [ Upstream commit df3accb849607a86278a37c35e6b313635ccc48b ]
      
      Allow the caller to pass error information when cleaning up a failed
      I/O request so that we can conditionally take action to cancel the
      request altogether if the error turned out to be fatal.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b5891b62
    • T
      NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend() · 812de6de
      Trond Myklebust 提交于
      [ Upstream commit f4340e9314dbfadc48758945f85fc3b16612d06f ]
      
      If the attempt to resend the pages fails, we need to ensure that we
      clean up those pages that were not transmitted.
      
      Fixes: d600ad1f ("NFS41: pop some layoutget errors to application")
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Cc: stable@vger.kernel.org # v4.5+
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      812de6de
    • T
      NFS: Clean up list moves of struct nfs_page · 57c491fd
      Trond Myklebust 提交于
      [ Upstream commit 078b5fd92c4913dd367361db6c28568386077c89 ]
      
      In several places we're just moving the struct nfs_page from one list to
      another by first removing from the existing list, then adding to the new
      one.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      57c491fd
    • M
      KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI · 79f1b33c
      Marc Zyngier 提交于
      [ Upstream commit 82e40f558de566fdee214bec68096bbd5e64a6a4 ]
      
      A guest is not allowed to inject a SGI (or clear its pending state)
      by writing to GICD_ISPENDR0 (resp. GICD_ICPENDR0), as these bits are
      defined as WI (as per ARM IHI 0048B 4.3.7 and 4.3.8).
      
      Make sure we correctly emulate the architecture.
      
      Fixes: 96b29800 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers")
      Cc: stable@vger.kernel.org # 4.7+
      Reported-by: NAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      79f1b33c
    • H
      KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long · ab8ecc27
      Heyi Guo 提交于
      [ Upstream commit d4a8061a7c5f7c27a2dc002ee4cb89b3e6637e44 ]
      
      If the ap_list is longer than 256 entries, merge_final() in list_sort()
      will call the comparison callback with the same element twice, causing
      a deadlock in vgic_irq_cmp().
      
      Fix it by returning early when irqa == irqb.
      
      Cc: stable@vger.kernel.org # 4.7+
      Fixes: 8e444745 ("KVM: arm/arm64: vgic-new: Add IRQ sorting")
      Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
      Signed-off-by: NHeyi Guo <guoheyi@huawei.com>
      [maz: massaged commit log and patch, added Fixes and Cc-stable]
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ab8ecc27
    • A
      KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling · db1841a2
      Alexey Kardashevskiy 提交于
      [ Upstream commit ddfd151f3def9258397fcde7a372205a2d661903 ]
      
      H_PUT_TCE_INDIRECT handlers receive a page with up to 512 TCEs from
      a guest. Although we verify correctness of TCEs before we do anything
      with the existing tables, there is a small window when a check in
      kvmppc_tce_validate might pass and right after that the guest alters
      the page of TCEs, causing an early exit from the handler and leaving
      srcu_read_lock(&vcpu->kvm->srcu) (virtual mode) or lock_rmap(rmap)
      (real mode) locked.
      
      This fixes the bug by jumping to the common exit code with an appropriate
      unlock.
      
      Cc: stable@vger.kernel.org # v4.11+
      Fixes: 121f80ba ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      db1841a2
    • D
      mac80211: Correctly set noencrypt for PAE frames · 938e3837
      Denis Kenzior 提交于
      commit f8b43c5cf4b62a19f2210a0f5367b84e1eff1ab9 upstream.
      
      The noencrypt flag was intended to be set if the "frame was received
      unencrypted" according to include/uapi/linux/nl80211.h.  However, the
      current behavior is opposite of this.
      
      Cc: stable@vger.kernel.org
      Fixes: 018f6fbf ("mac80211: Send control port frames over nl80211")
      Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
      Link: https://lore.kernel.org/r/20190827224120.14545-3-denkenz@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      938e3837
    • D
      mac80211: Don't memset RXCB prior to PAE intercept · 4f139c03
      Denis Kenzior 提交于
      commit c8a41c6afa27b8c3f61622dfd882b912da9d6721 upstream.
      
      In ieee80211_deliver_skb_to_local_stack intercepts EAPoL frames if
      mac80211 is configured to do so and forwards the contents over nl80211.
      During this process some additional data is also forwarded, including
      whether the frame was received encrypted or not.  Unfortunately just
      prior to the call to ieee80211_deliver_skb_to_local_stack, skb->cb is
      cleared, resulting in incorrect data being exposed over nl80211.
      
      Fixes: 018f6fbf ("mac80211: Send control port frames over nl80211")
      Cc: stable@vger.kernel.org
      Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
      Link: https://lore.kernel.org/r/20190827224120.14545-2-denkenz@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f139c03
    • J
      mac80211: fix possible sta leak · 58f91aac
      Johannes Berg 提交于
      commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.
      
      If TDLS station addition is rejected, the sta memory is leaked.
      Avoid this by moving the check before the allocation.
      
      Cc: stable@vger.kernel.org
      Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
      Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58f91aac
    • H
      Revert "cfg80211: fix processing world regdomain when non modular" · 945b3597
      Hodaszi, Robert 提交于
      commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.
      
      This reverts commit 96cce12f ("cfg80211: fix processing world
      regdomain when non modular").
      
      Re-triggering a reg_process_hint with the last request on all events,
      can make the regulatory domain fail in case of multiple WiFi modules. On
      slower boards (espacially with mdev), enumeration of the WiFi modules
      can end up in an intersected regulatory domain, and user cannot set it
      with 'iw reg set' anymore.
      
      This is happening, because:
      - 1st module enumerates, queues up a regulatory request
      - request gets processed by __reg_process_hint_driver():
        - checks if previous was set by CORE -> yes
          - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
            -> sends request to the 'crda'
      - 2nd module enumerates, queues up a regulator request (which triggers
        the reg_todo() work)
      - reg_todo() -> reg_process_pending_hints() sees, that the last request
        is not processed yet, so it tries to process it again.
        __reg_process_hint driver() will run again, and:
        - checks if the last request's initiator was the core -> no, it was
          the driver (1st WiFi module)
        - checks, if the previous initiator was the driver -> yes
          - checks if the regulator domain changed -> yes, it was '00' (set by
            core, and crda call did not return yet), and should be changed to 'US'
      
      ------> __reg_process_hint_driver calls an intersect
      
      Besides, the reg_process_hint call with the last request is meaningless
      since the crda call has a timeout work. If that timeout expires, the
      first module's request will lost.
      
      Cc: stable@vger.kernel.org
      Fixes: 96cce12f ("cfg80211: fix processing world regdomain when non modular")
      Signed-off-by: NRobert Hodaszi <robert.hodaszi@digi.com>
      Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hrSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      945b3597
    • G
      crypto: ccp - Ignore unconfigured CCP device on suspend/resume · 690a4248
      Gary R Hook 提交于
      commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.
      
      If a CCP is unconfigured (e.g. there are no available queues) then
      there will be no data structures allocated for the device. Thus, we
      must check for validity of a pointer before trying to access structure
      members.
      
      Fixes: 720419f0 ("crypto: ccp - Introduce the AMD Secure Processor device")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      690a4248
    • N
      VMCI: Release resource if the work is already queued · 4e77b2ea
      Nadav Amit 提交于
      commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.
      
      Francois reported that VMware balloon gets stuck after a balloon reset,
      when the VMCI doorbell is removed. A similar error can occur when the
      balloon driver is removed with the following splat:
      
      [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
      [ 1088.622035]       Tainted: G        W         5.2.0 #4
      [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
      [ 1088.622210] Call Trace:
      [ 1088.622246]  __schedule+0x2a8/0x690
      [ 1088.622248]  schedule+0x2d/0x90
      [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
      [ 1088.622252]  wait_for_completion+0xba/0x140
      [ 1088.622320]  ? wake_up_q+0x80/0x80
      [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
      [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
      [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
      [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
      [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
      [ 1088.622408]  do_syscall_64+0x5a/0x130
      [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 1088.622415] RIP: 0033:0x7f54f62791b7
      [ 1088.622421] Code: Bad RIP value.
      [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
      [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
      [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
      [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
      [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0
      
      The cause for the bug is that when the "delayed" doorbell is invoked, it
      takes a reference on the doorbell entry and schedules work that is
      supposed to run the appropriate code and drop the doorbell entry
      reference. The code ignores the fact that if the work is already queued,
      it will not be scheduled to run one more time. As a result one of the
      references would not be dropped. When the code waits for the reference
      to get to zero, during balloon reset or module removal, it gets stuck.
      
      Fix it. Drop the reference if schedule_work() indicates that the work is
      already queued.
      
      Note that this bug got more apparent (or apparent at all) due to
      commit ce664331 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").
      
      Fixes: 83e2ec76 ("VMCI: doorbell implementation.")
      Reported-by: NFrancois Rigault <rigault.francois@gmail.com>
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Cc: Adit Ranadive <aditr@vmware.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Vishnu DASA <vdasa@vmware.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Reviewed-by: NVishnu Dasa <vdasa@vmware.com>
      Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e77b2ea
    • J
      bus: hisi_lpc: Add .remove method to avoid driver unbind crash · 2a964875
      John Garry 提交于
      commit 10e62b47973b0b0ceda076255bcb147b83e20517 upstream.
      
      The original driver author seemed to be under the impression that a driver
      cannot be removed if it does not have a .remove method. Or maybe if it is
      a built-in platform driver.
      
      This is not true. This crash can be created:
      
      root@ubuntu:/sys/bus/platform/drivers/hisi-lpc# echo HISI0191\:00 > unbind
      root@ubuntu:/sys/bus/platform/drivers/hisi-lpc# ipmitool raw 6 1
       Unable to handle kernel paging request at virtual address ffff000010035010
       Mem abort info:
         ESR = 0x96000047
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000047
         CM = 0, WnR = 1
       swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000118b000
       [ffff000010035010] pgd=0000041ffbfff003, pud=0000041ffbffe003, pmd=0000041ffbffd003, pte=0000000000000000
       Internal error: Oops: 96000047 [#1] PREEMPT SMP
       Modules linked in:
       CPU: 17 PID: 1473 Comm: ipmitool Not tainted 5.2.0-rc5-00003-gf68c53b414a3-dirty #198
       Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
       pstate: 20000085 (nzCv daIf -PAN -UAO)
       pc : hisi_lpc_target_in+0x7c/0x120
       lr : hisi_lpc_target_in+0x70/0x120
       sp : ffff00001efe3930
       x29: ffff00001efe3930 x28: ffff841f9f599200
       x27: 0000000000000002 x26: 0000000000000000
       x25: 0000000000000080 x24: 00000000000000e4
       x23: 0000000000000000 x22: 0000000000000064
       x21: ffff801fb667d280 x20: 0000000000000001
       x19: ffff00001efe39ac x18: 0000000000000000
       x17: 0000000000000000 x16: 0000000000000000
       x15: 0000000000000000 x14: 0000000000000000
       x13: 0000000000000000 x12: 0000000000000000
       x11: 0000000000000000 x10: 0000000000000000
       x9 : 0000000000000000 x8 : ffff841febe60340
       x7 : ffff801fb55c52e8 x6 : 0000000000000000
       x5 : 0000000000ffc0e3 x4 : 0000000000000001
       x3 : ffff801fb667d280 x2 : 0000000000000001
       x1 : ffff000010035010 x0 : ffff000010035000
       Call trace:
        hisi_lpc_target_in+0x7c/0x120
        hisi_lpc_comm_in+0x88/0x98
        logic_inb+0x5c/0xb8
        port_inb+0x18/0x20
        bt_event+0x38/0x808
        smi_event_handler+0x4c/0x5a0
        check_start_timer_thread.part.4+0x40/0x58
        sender+0x78/0x88
        smi_send.isra.6+0x94/0x108
        i_ipmi_request+0x2c4/0x8f8
        ipmi_request_settime+0x124/0x160
        handle_send_req+0x19c/0x208
        ipmi_ioctl+0x2c0/0x990
        do_vfs_ioctl+0xb8/0x8f8
        ksys_ioctl+0x80/0xb8
        __arm64_sys_ioctl+0x1c/0x28
        el0_svc_common.constprop.0+0x64/0x160
        el0_svc_handler+0x28/0x78
        el0_svc+0x8/0xc
       Code: 941d1511 aa0003f9 f94006a0 91004001 (b9000034)
       ---[ end trace aa842b86af7069e4 ]---
      
      The problem here is that the host goes away but the associated logical PIO
      region remains registered, as do the children devices.
      
      Fix by adding a .remove method to tidy-up by removing the child devices
      and unregistering the logical PIO region.
      
      Cc: stable@vger.kernel.org
      Fixes: adf38bb0 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings")
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NWei Xu <xuwei5@hisilicon.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a964875
    • J
      bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free · 649532ef
      John Garry 提交于
      commit 1b15a5632a809ab57d403fd972ca68785363b654 upstream.
      
      If, after registering a logical PIO range, the driver probe later fails,
      the logical PIO range memory will be released automatically.
      
      This causes an issue, in that the logical PIO range is not unregistered
      and the released range memory may be later referenced.
      
      Fix by unregistering the logical PIO range.
      
      And since we now unregister the logical PIO range for probe failure, avoid
      the special ordering of setting logical PIO range ops, which was the
      previous (poor) attempt at a safeguard against this.
      
      Cc: stable@vger.kernel.org
      Fixes: adf38bb0 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings")
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NWei Xu <xuwei5@hisilicon.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      649532ef