1. 23 6月, 2022 9 次提交
  2. 22 6月, 2022 7 次提交
    • J
      Revert "drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c" · 877fe9d4
      Jakub Kicinski 提交于
      This reverts commit 8fc74d18.
      
      BAR0 is the main (only?) register bank for this device. We most
      obviously can't unmap it before the netdev is unregistered.
      This was pointed out in review but the patch got reposted and
      merged, anyway.
      
      The author of the patch was only testing it with a QEMU model,
      which I presume does not emulate enough for the netdev to be brought
      up (author's replies are not visible in lore because they kept sending
      their emails in HTML).
      
      Link: https://lore.kernel.org/all/20220616085059.680dc215@kernel.org/
      Fixes: 8fc74d18 ("drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c")
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      877fe9d4
    • J
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · 53664d51
      Jakub Kicinski 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      1) Use get_random_u32() instead of prandom_u32_state() in nft_meta
         and nft_numgen, from Florian Westphal.
      
      2) Incorrect list head in nfnetlink_cttimeout in recent update coming
         from previous development cycle. Also from Florian.
      
      3) Incorrect path to pktgen scripts for nft_concat_range.sh selftest.
         From Jie2x Zhou.
      
      4) Two fixes for the for nft_fwd and nft_dup egress support, from Florian.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
        netfilter: nf_dup_netdev: add and use recursion counter
        netfilter: nf_dup_netdev: do not push mac header a second time
        selftests: netfilter: correct PKTGEN_SCRIPT_PATHS in nft_concat_range.sh
        netfilter: cttimeout: fix slab-out-of-bounds read typo in cttimeout_net_exit
        netfilter: use get_random_u32 instead of prandom
      ====================
      
      Link: https://lore.kernel.org/r/20220621085618.3975-1-pablo@netfilter.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      53664d51
    • L
      net: phy: smsc: Disable Energy Detect Power-Down in interrupt mode · 2642cc6c
      Lukas Wunner 提交于
      Simon reports that if two LAN9514 USB adapters are directly connected
      without an intermediate switch, the link fails to come up and link LEDs
      remain dark.  The issue was introduced by commit 1ce8b372 ("usbnet:
      smsc95xx: Forward PHY interrupts to PHY driver to avoid polling").
      
      The PHY suffers from a known erratum wherein link detection becomes
      unreliable if Energy Detect Power-Down is used.  In poll mode, the
      driver works around the erratum by briefly disabling EDPD for 640 msec
      to detect a neighbor, then re-enabling it to save power.
      
      In interrupt mode, no interrupt is signaled if EDPD is used by both link
      partners, so it must not be enabled at all.
      
      We'll recoup the power savings by enabling SUSPEND1 mode on affected
      LAN95xx chips in a forthcoming commit.
      
      Fixes: 1ce8b372 ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling")
      Reported-by: NSimon Han <z.han@kunbus.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Link: https://lore.kernel.org/r/439a3f3168c2f9d44b5fd9bb8d2b551711316be6.1655714438.git.lukas@wunner.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      2642cc6c
    • A
      ice: ethtool: Prohibit improper channel config for DCB · a632b2a4
      Anatolii Gerasymenko 提交于
      Do not allow setting less channels, than Traffic Classes there are
      via ethtool. There must be at least one channel per Traffic Class.
      
      If you set less channels, than Traffic Classes there are, then during
      ice_vsi_rebuild there would be allocated only the requested amount
      of tx/rx rings in ice_vsi_alloc_arrays. But later in ice_vsi_setup_q_map
      there would be requested at least one channel per Traffic Class. This
      results in setting num_rxq > alloc_rxq and num_txq > alloc_txq.
      Later, there would be a NULL pointer dereference in
      ice_vsi_map_rings_to_vectors, because we go beyond of rx_rings or
      tx_rings arrays.
      
      Change ice_set_channels() to return error if you try to allocate less
      channels, than Traffic Classes there are.
      Change ice_vsi_setup_q_map() and ice_vsi_setup_q_map_mqprio() to return
      status code instead of void.
      Add error handling for ice_vsi_setup_q_map() and
      ice_vsi_setup_q_map_mqprio() in ice_vsi_init() and ice_vsi_cfg_tc().
      
      [53753.889983] INFO: Flow control is disabled for this traffic class (0) on this vsi.
      [53763.984862] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      [53763.992915] PGD 14b45f5067 P4D 0
      [53763.996444] Oops: 0002 [#1] SMP NOPTI
      [53764.000312] CPU: 12 PID: 30661 Comm: ethtool Kdump: loaded Tainted: GOE    --------- -  - 4.18.0-240.el8.x86_64 #1
      [53764.011825] Hardware name: Intel Corporation WilsonCity/WilsonCity, BIOS WLYDCRB1.SYS.0020.P21.2012150710 12/15/2020
      [53764.022584] RIP: 0010:ice_vsi_map_rings_to_vectors+0x7e/0x120 [ice]
      [53764.029089] Code: 41 0d 0f b7 b7 12 05 00 00 0f b6 d0 44 29 de 44 0f b7 c6 44 01 c2 41 39 d0 7d 2d 4c 8b 47 28 44 0f b7 ce 83 c6 01 4f 8b 04 c8 <49> 89 48 28 4                           c 8b 89 b8 01 00 00 4d 89 08 4c 89 81 b8 01 00 00 44
      [53764.048379] RSP: 0018:ff550dd88ea47b20 EFLAGS: 00010206
      [53764.053884] RAX: 0000000000000002 RBX: 0000000000000004 RCX: ff385ea42fa4a018
      [53764.061301] RDX: 0000000000000006 RSI: 0000000000000005 RDI: ff385e9baeedd018
      [53764.068717] RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000004
      [53764.076133] R10: 0000000000000002 R11: 0000000000000004 R12: 0000000000000000
      [53764.083553] R13: 0000000000000000 R14: ff385e658fdd9000 R15: ff385e9baeedd018
      [53764.090976] FS:  000014872c5b5740(0000) GS:ff385e847f100000(0000) knlGS:0000000000000000
      [53764.099362] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [53764.105409] CR2: 0000000000000028 CR3: 0000000a820fa002 CR4: 0000000000761ee0
      [53764.112851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [53764.120301] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [53764.127747] PKRU: 55555554
      [53764.130781] Call Trace:
      [53764.133564]  ice_vsi_rebuild+0x611/0x870 [ice]
      [53764.138341]  ice_vsi_recfg_qs+0x94/0x100 [ice]
      [53764.143116]  ice_set_channels+0x1a8/0x3e0 [ice]
      [53764.147975]  ethtool_set_channels+0x14e/0x240
      [53764.152667]  dev_ethtool+0xd74/0x2a10
      [53764.156665]  ? __mod_lruvec_state+0x44/0x110
      [53764.161280]  ? __mod_lruvec_state+0x44/0x110
      [53764.165893]  ? page_add_file_rmap+0x15/0x170
      [53764.170518]  ? inet_ioctl+0xd1/0x220
      [53764.174445]  ? netdev_run_todo+0x5e/0x290
      [53764.178808]  dev_ioctl+0xb5/0x550
      [53764.182485]  sock_do_ioctl+0xa0/0x140
      [53764.186512]  sock_ioctl+0x1a8/0x300
      [53764.190367]  ? selinux_file_ioctl+0x161/0x200
      [53764.195090]  do_vfs_ioctl+0xa4/0x640
      [53764.199035]  ksys_ioctl+0x60/0x90
      [53764.202722]  __x64_sys_ioctl+0x16/0x20
      [53764.206845]  do_syscall_64+0x5b/0x1a0
      [53764.210887]  entry_SYSCALL_64_after_hwframe+0x65/0xca
      
      Fixes: 87324e74 ("ice: Implement ethtool ops for channels")
      Signed-off-by: NAnatolii Gerasymenko <anatolii.gerasymenko@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      a632b2a4
    • A
      ice: ethtool: advertise 1000M speeds properly · c3d184c8
      Anatolii Gerasymenko 提交于
      In current implementation ice_update_phy_type enables all link modes
      for selected speed. This approach doesn't work for 1000M speeds,
      because both copper (1000baseT) and optical (1000baseX) standards
      cannot be enabled at once.
      
      Fix this, by adding the function `ice_set_phy_type_from_speed()`
      for 1000M speeds.
      
      Fixes: 48cb27f2 ("ice: Implement handlers for ethtool PHY/link operations")
      Signed-off-by: NAnatolii Gerasymenko <anatolii.gerasymenko@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      c3d184c8
    • W
      ice: Fix switchdev rules book keeping · 3578dc90
      Wojciech Drewek 提交于
      Adding two filters with same matching criteria ends up with
      one rule in hardware with act = ICE_FWD_TO_VSI_LIST.
      In order to remove them properly we have to keep the
      information about vsi handle which is used in VSI bitmap
      (ice_adv_fltr_mgmt_list_entry::vsi_list_info::vsi_map).
      
      Fixes: 0d08a441 ("ice: ndo_setup_tc implementation for PF")
      Reported-by: NSridhar Samudrala <sridhar.samudrala@intel.com>
      Signed-off-by: NWojciech Drewek <wojciech.drewek@intel.com>
      Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      3578dc90
    • M
      ice: ignore protocol field in GTP offload · d4ea6f63
      Marcin Szycik 提交于
      Commit 34a89775 ("ice: Add support for inner etype in switchdev")
      added the ability to match on inner ethertype. A side effect of that change
      is that it is now impossible to add some filters for protocols which do not
      contain inner ethtype field. tc requires the protocol field to be specified
      when providing certain other options, e.g. src_ip. This is a problem in
      case of GTP - when user wants to specify e.g. src_ip, they also need to
      specify protocol in tc command (otherwise tc fails with: Illegal "src_ip").
      Because GTP is a tunnel, the protocol field is treated as inner protocol.
      GTP does not contain inner ethtype field and the filter cannot be added.
      
      To fix this, ignore the ethertype field in case of GTP filters.
      
      Fixes: 9a225f81 ("ice: Support GTP-U and GTP-C offload in switchdev")
      Signed-off-by: NMarcin Szycik <marcin.szycik@linux.intel.com>
      Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      d4ea6f63
  3. 21 6月, 2022 3 次提交
  4. 20 6月, 2022 3 次提交
    • Z
      net/tls: fix tls_sk_proto_close executed repeatedly · 69135c57
      Ziyang Xuan 提交于
      After setting the sock ktls, update ctx->sk_proto to sock->sk_prot by
      tls_update(), so now ctx->sk_proto->close is tls_sk_proto_close(). When
      close the sock, tls_sk_proto_close() is called for sock->sk_prot->close
      is tls_sk_proto_close(). But ctx->sk_proto->close() will be executed later
      in tls_sk_proto_close(). Thus tls_sk_proto_close() executed repeatedly
      occurred. That will trigger the following bug.
      
      =================================================================
      KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
      RIP: 0010:tls_sk_proto_close+0xd8/0xaf0 net/tls/tls_main.c:306
      Call Trace:
       <TASK>
       tls_sk_proto_close+0x356/0xaf0 net/tls/tls_main.c:329
       inet_release+0x12e/0x280 net/ipv4/af_inet.c:428
       __sock_release+0xcd/0x280 net/socket.c:650
       sock_close+0x18/0x20 net/socket.c:1365
      
      Updating a proto which is same with sock->sk_prot is incorrect. Add proto
      and sock->sk_prot equality check at the head of tls_update() to fix it.
      
      Fixes: 95fa1454 ("bpf: sockmap/tls, close can race with map free")
      Reported-by: syzbot+29c3c12f3214b85ad081@syzkaller.appspotmail.com
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69135c57
    • E
      erspan: do not assume transport header is always set · 301bd140
      Eric Dumazet 提交于
      Rewrite tests in ip6erspan_tunnel_xmit() and
      erspan_fb_xmit() to not assume transport header is set.
      
      syzbot reported:
      
      WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
      WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
      Modules linked in:
      CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6 #0
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
      RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
      RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
      Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
      RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
      RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
      RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
      R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
      R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
      FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
      Call Trace:
      <TASK>
      __netdev_start_xmit include/linux/netdevice.h:4805 [inline]
      netdev_start_xmit include/linux/netdevice.h:4819 [inline]
      xmit_one net/core/dev.c:3588 [inline]
      dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604
      sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342
      __dev_xmit_skb net/core/dev.c:3815 [inline]
      __dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219
      dev_queue_xmit include/linux/netdevice.h:2994 [inline]
      tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63
      kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229
      kthread+0x2e9/0x3a0 kernel/kthread.c:376
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
      </TASK>
      
      Fixes: d5db21a3 ("erspan: auto detect truncated ipv6 packets.")
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: William Tu <u9012063@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      301bd140
    • R
      ipv4: fix bind address validity regression tests · 313c502f
      Riccardo Paolo Bestetti 提交于
      Commit 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses")
      introduces support for binding to nonlocal addresses, as well as some
      basic test coverage for some of the related cases.
      
      Commit b4a028c4 ("ipv4: ping: fix bind address validity check")
      fixes a regression which incorrectly removed some checks for bind
      address validation. In addition, it introduces regression tests for
      those specific checks. However, those regression tests are defective, in
      that they perform the tests using an incorrect combination of bind
      flags. As a result, those tests fail when they should succeed.
      
      This commit introduces additional regression tests for nonlocal binding
      and fixes the defective regression tests. It also introduces new
      set_sysctl calls for the ipv4_bind test group, as to perform the ICMP
      binding tests it is necessary to allow ICMP socket creation by setting
      the net.ipv4.ping_group_range knob.
      
      Fixes: b4a028c4 ("ipv4: ping: fix bind address validity check")
      Reported-by: NRiccardo Paolo Bestetti <pbl@bestov.io>
      Signed-off-by: NRiccardo Paolo Bestetti <pbl@bestov.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      313c502f
  5. 19 6月, 2022 2 次提交
    • O
      net: phy: at803x: fix NULL pointer dereference on AR9331 PHY · 9926de73
      Oleksij Rempel 提交于
      Latest kernel will explode on the PHY interrupt config, since it depends
      now on allocated priv. So, run probe to allocate priv to fix it.
      
       ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13)
       CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34
               ...
       Call Trace:
       [<8050e8a8>] at803x_config_intr+0x5c/0xd0
       [<80504b34>] phy_request_interrupt+0xa8/0xd0
       [<8050289c>] phylink_bringup_phy+0x2d8/0x3ac
       [<80502b68>] phylink_fwnode_phy_connect+0x118/0x130
       [<8074d8ec>] dsa_slave_create+0x270/0x420
       [<80743b04>] dsa_port_setup+0x12c/0x148
       [<8074580c>] dsa_register_switch+0xaf0/0xcc0
       [<80511344>] ar9331_sw_probe+0x370/0x388
       [<8050cb78>] mdio_probe+0x44/0x70
       [<804df300>] really_probe+0x200/0x424
       [<804df7b4>] __driver_probe_device+0x290/0x298
       [<804df810>] driver_probe_device+0x54/0xe4
       [<804dfd50>] __device_attach_driver+0xe4/0x130
       [<804dcb00>] bus_for_each_drv+0xb4/0xd8
       [<804dfac4>] __device_attach+0x104/0x1a4
       [<804ddd24>] bus_probe_device+0x48/0xc4
       [<804deb44>] deferred_probe_work_func+0xf0/0x10c
       [<800a0ffc>] process_one_work+0x314/0x4d4
       [<800a17fc>] worker_thread+0x2a4/0x354
       [<800a9a54>] kthread+0x134/0x13c
       [<8006306c>] ret_from_kernel_thread+0x14/0x1c
      
      Same Issue would affect some other PHYs (QCA8081, QCA9561), so fix it
      too.
      
      Fixes: 3265f421 ("net: phy: at803x: add fiber support")
      Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9926de73
    • W
      drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c · 8fc74d18
      Wentao_Liang 提交于
      The pointer vdev points to a memory region adjacent to a net_device
      structure ndev, which is a field of hldev. At line 4740, the invocation
      to vxge_device_unregister unregisters device hldev, and it also releases
      the memory region pointed by vdev->bar0. At line 4743, the freed memory
      region is referenced (i.e., iounmap(vdev->bar0)), resulting in a
      use-after-free vulnerability. We can fix the bug by calling iounmap
      before vxge_device_unregister.
      
      4721.      static void vxge_remove(struct pci_dev *pdev)
      4722.      {
      4723.             struct __vxge_hw_device *hldev;
      4724.             struct vxgedev *vdev;
      …
      4731.             vdev = netdev_priv(hldev->ndev);
      …
      4740.             vxge_device_unregister(hldev);
      4741.             /* Do not call pci_disable_sriov here, as it
      						will break child devices */
      4742.             vxge_hw_device_terminate(hldev);
      4743.             iounmap(vdev->bar0);
      …
      4749              vxge_debug_init(vdev->level_trace, "%s:%d
      								Device unregistered",
      4750                            __func__, __LINE__);
      4751              vxge_debug_entryexit(vdev->level_trace, "%s:%d
      								Exiting...", __func__,
      4752                          __LINE__);
      4753.      }
      
      This is the screenshot when the vulnerability is triggered by using
      KASAN. We can see that there is a use-after-free reported by KASAN.
      
      /***************************start**************************/
      
      root@kernel:~# echo 1 > /sys/bus/pci/devices/0000:00:03.0/remove
      [  178.296316] vxge_remove
      [  182.057081]
       ==================================================================
      [  182.057548] BUG: KASAN: use-after-free in vxge_remove+0xe0/0x15c
      [  182.057760] Read of size 8 at addr ffff888006c76598 by task bash/119
      [  182.057983]
      [  182.058747] CPU: 0 PID: 119 Comm: bash Not tainted 5.18.0 #5
      [  182.058919] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      [  182.059463] Call Trace:
      [  182.059726]  <TASK>
      [  182.060017]  dump_stack_lvl+0x34/0x44
      [  182.060316]  print_report.cold+0xb2/0x6b7
      [  182.060401]  ? kfree+0x89/0x290
      [  182.060478]  ? vxge_remove+0xe0/0x15c
      [  182.060545]  kasan_report+0xa9/0x120
      [  182.060629]  ? vxge_remove+0xe0/0x15c
      [  182.060706]  vxge_remove+0xe0/0x15c
      [  182.060793]  pci_device_remove+0x5d/0xe0
      [  182.060968]  device_release_driver_internal+0xf1/0x180
      [  182.061063]  pci_stop_bus_device+0xae/0xe0
      [  182.061150]  pci_stop_and_remove_bus_device_locked+0x11/0x20
      [  182.061236]  remove_store+0xc6/0xe0
      [  182.061297]  ? subordinate_bus_number_show+0xc0/0xc0
      [  182.061359]  ? __mutex_lock_slowpath+0x10/0x10
      [  182.061438]  ? sysfs_kf_write+0x6d/0xa0
      [  182.061525]  kernfs_fop_write_iter+0x1b0/0x260
      [  182.061610]  ? sysfs_kf_bin_read+0xf0/0xf0
      [  182.061695]  new_sync_write+0x209/0x310
      [  182.061789]  ? new_sync_read+0x310/0x310
      [  182.061865]  ? cgroup_rstat_updated+0x5c/0x170
      [  182.061937]  ? preempt_count_sub+0xf/0xb0
      [  182.061995]  ? pick_next_entity+0x13a/0x220
      [  182.062063]  ? __inode_security_revalidate+0x44/0x80
      [  182.062155]  ? security_file_permission+0x46/0x2a0
      [  182.062230]  vfs_write+0x33f/0x3e0
      [  182.062303]  ksys_write+0xb4/0x150
      [  182.062369]  ? __ia32_sys_read+0x40/0x40
      [  182.062451]  do_syscall_64+0x3b/0x90
      [  182.062531]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [  182.062894] RIP: 0033:0x7f3f37d17274
      [  182.063558] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f
      80 00 00 00 00 48 8d 05 89 54 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f
      05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
      [  182.063797] RSP: 002b:00007ffd5ba9e178 EFLAGS: 00000246
      ORIG_RAX: 0000000000000001
      [  182.064117] RAX: ffffffffffffffda RBX: 0000000000000002
      RCX: 00007f3f37d17274
      [  182.064219] RDX: 0000000000000002 RSI: 000055bbec327180
      RDI: 0000000000000001
      [  182.064315] RBP: 000055bbec327180 R08: 000000000000000a
      R09: 00007f3f37de7cf0
      [  182.064414] R10: 000000000000000a R11: 0000000000000246
      R12: 00007f3f37de8760
      [  182.064513] R13: 0000000000000002 R14: 00007f3f37de3760
      R15: 0000000000000002
      [  182.064691]  </TASK>
      [  182.064916]
      [  182.065224] The buggy address belongs to the physical page:
      [  182.065804] page:00000000ef31e4f4 refcount:0 mapcount:0
      mapping:0000000000000000 index:0x0 pfn:0x6c76
      [  182.067419] flags: 0x100000000000000(node=0|zone=1)
      [  182.068997] raw: 0100000000000000 0000000000000000
      ffffea00001b1d88 0000000000000000
      [  182.069118] raw: 0000000000000000 0000000000000000
      00000000ffffffff 0000000000000000
      [  182.069294] page dumped because: kasan: bad access detected
      [  182.069331]
      [  182.069360] Memory state around the buggy address:
      [  182.070006]  ffff888006c76480: ff ff ff ff ff ff ff ff ff ff ff
       ff ff ff ff ff
      [  182.070136]  ffff888006c76500: ff ff ff ff ff ff ff ff ff ff ff
       ff ff ff ff ff
      [  182.070230] >ffff888006c76580: ff ff ff ff ff ff ff ff ff ff ff
       ff ff ff ff ff
      [  182.070305]                             ^
      [  182.070456]  ffff888006c76600: ff ff ff ff ff ff ff ff ff ff ff
       ff ff ff ff ff
      [  182.070505]  ffff888006c76680: ff ff ff ff ff ff ff ff ff ff ff
       ff ff ff ff ff
      [  182.070606]
      ==================================================================
      [  182.071374] Disabling lock debugging due to kernel taint
      
      /*****************************end*****************************/
      
      After fixing the bug as done in the patch, we can find KASAN do not report
       the bug and the device(00:03.0) has been successfully removed.
      
      /*****************************start***************************/
      
      root@kernel:~# echo 1 > /sys/bus/pci/devices/0000:00:03.0/remove
      root@kernel:~#
      
      /******************************end****************************/
      Signed-off-by: NWentao_Liang <Wentao_Liang_g@163.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8fc74d18
  6. 18 6月, 2022 9 次提交
  7. 17 6月, 2022 7 次提交
    • R
      ipv4: ping: fix bind address validity check · b4a028c4
      Riccardo Paolo Bestetti 提交于
      Commit 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses")
      introduced a helper function to fold duplicated validity checks of bind
      addresses into inet_addr_valid_or_nonlocal(). However, this caused an
      unintended regression in ping_check_bind_addr(), which previously would
      reject binding to multicast and broadcast addresses, but now these are
      both incorrectly allowed as reported in [1].
      
      This patch restores the original check. A simple reordering is done to
      improve readability and make it evident that multicast and broadcast
      addresses should not be allowed. Also, add an early exit for INADDR_ANY
      which replaces lost behavior added by commit 0ce779a9 ("net: Avoid
      unnecessary inet_addr_type() call when addr is INADDR_ANY").
      
      Furthermore, this patch introduces regression selftests to catch these
      specific cases.
      
      [1] https://lore.kernel.org/netdev/CANP3RGdkAcDyAZoT1h8Gtuu0saq+eOrrTiWbxnOs+5zn+cpyKg@mail.gmail.com/
      
      Fixes: 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses")
      Cc: Miaohe Lin <linmiaohe@huawei.com>
      Reported-by: NMaciej Żenczykowski <maze@google.com>
      Signed-off-by: NCarlos Llamas <cmllamas@google.com>
      Signed-off-by: NRiccardo Paolo Bestetti <pbl@bestov.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4a028c4
    • X
      hamradio: 6pack: fix array-index-out-of-bounds in decode_std_command() · 2b04495e
      Xu Jia 提交于
      Hulk Robot reports incorrect sp->rx_count_cooked value in decode_std_command().
      This should be caused by the subtracting from sp->rx_count_cooked before.
      It seems that sp->rx_count_cooked value is changed to 0, which bypassed the
      previous judgment.
      
      The situation is shown below:
      
               (Thread 1)			|  (Thread 2)
      decode_std_command()		| resync_tnc()
      ...					|
      if (rest == 2)			|
      	sp->rx_count_cooked -= 2;	|
      else if (rest == 3)			| ...
      					| sp->rx_count_cooked = 0;
      	sp->rx_count_cooked -= 1;	|
      for (i = 0; i < sp->rx_count_cooked; i++) // report error
      	checksum += sp->cooked_buf[i];
      
      sp->rx_count_cooked is a shared variable but is not protected by a lock.
      The same applies to sp->rx_count. This patch adds a lock to fix the bug.
      
      The fail log is shown below:
      =======================================================================
      UBSAN: array-index-out-of-bounds in drivers/net/hamradio/6pack.c:925:31
      index 400 is out of range for type 'unsigned char [400]'
      CPU: 3 PID: 7433 Comm: kworker/u10:1 Not tainted 5.18.0-rc5-00163-g4b97bac0 #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      Workqueue: events_unbound flush_to_ldisc
      Call Trace:
       <TASK>
       dump_stack_lvl+0xcd/0x134
       ubsan_epilogue+0xb/0x50
       __ubsan_handle_out_of_bounds.cold+0x62/0x6c
       sixpack_receive_buf+0xfda/0x1330
       tty_ldisc_receive_buf+0x13e/0x180
       tty_port_default_receive_buf+0x6d/0xa0
       flush_to_ldisc+0x213/0x3f0
       process_one_work+0x98f/0x1620
       worker_thread+0x665/0x1080
       kthread+0x2e9/0x3a0
       ret_from_fork+0x1f/0x30
       ...
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NXu Jia <xujia39@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b04495e
    • H
      tipc: fix use-after-free Read in tipc_named_reinit · 911600bf
      Hoang Le 提交于
      syzbot found the following issue on:
      ==================================================================
      BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0
      net/tipc/name_distr.c:413
      Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764
      
      CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted
      5.18.0-rc4-syzkaller-00878-g17d49e6e #0
      Hardware name: Google Compute Engine/Google Compute Engine,
      BIOS Google 01/01/2011
      Workqueue: events tipc_net_finalize_work
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description.constprop.0.cold+0xeb/0x495
      mm/kasan/report.c:313
       print_report mm/kasan/report.c:429 [inline]
       kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
       tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413
       tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138
       process_one_work+0x996/0x1610 kernel/workqueue.c:2289
       worker_thread+0x665/0x1080 kernel/workqueue.c:2436
       kthread+0x2e9/0x3a0 kernel/kthread.c:376
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
       </TASK>
      [...]
      ==================================================================
      
      In the commit
      d966ddcc ("tipc: fix a deadlock when flushing scheduled work"),
      the cancel_work_sync() function just to make sure ONLY the work
      tipc_net_finalize_work() is executing/pending on any CPU completed before
      tipc namespace is destroyed through tipc_exit_net(). But this function
      is not guaranteed the work is the last queued. So, the destroyed instance
      may be accessed in the work which will try to enqueue later.
      
      In order to completely fix, we re-order the calling of cancel_work_sync()
      to make sure the work tipc_net_finalize_work() was last queued and it
      must be completed by calling cancel_work_sync().
      
      Reported-by: syzbot+47af19f3307fc9c5c82e@syzkaller.appspotmail.com
      Fixes: d966ddcc ("tipc: fix a deadlock when flushing scheduled work")
      Acked-by: NJon Maloy <jmaloy@redhat.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      911600bf
    • J
      veth: Add updating of trans_start · e66e257a
      Jay Vosburgh 提交于
      Since commit 21a75f09 ("bonding: Fix ARP monitor validation"),
      the bonding ARP / ND link monitors depend on the trans_start time to
      determine link availability.  NETIF_F_LLTX drivers must update trans_start
      directly, which veth does not do.  This prevents use of the ARP or ND link
      monitors with veth interfaces in a bond.
      
      	Resolve this by having veth_xmit update the trans_start time.
      Reported-by: NJonathan Toppins <jtoppins@redhat.com>
      Tested-by: NJonathan Toppins <jtoppins@redhat.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 21a75f09 ("bonding: Fix ARP monitor validation")
      Link: https://lore.kernel.org/netdev/b2fd4147-8f50-bebd-963a-1a3e8d1d9715@redhat.com/Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e66e257a
    • E
      net: fix data-race in dev_isalive() · cc26c266
      Eric Dumazet 提交于
      dev_isalive() is called under RTNL or dev_base_lock protection.
      
      This means that changes to dev->reg_state should be done with both locks held.
      
      syzbot reported:
      
      BUG: KCSAN: data-race in register_netdevice / type_show
      
      write to 0xffff888144ecf518 of 1 bytes by task 20886 on cpu 0:
      register_netdevice+0xb9f/0xdf0 net/core/dev.c:10050
      lapbeth_new_device drivers/net/wan/lapbether.c:414 [inline]
      lapbeth_device_event+0x4a0/0x6c0 drivers/net/wan/lapbether.c:456
      notifier_call_chain kernel/notifier.c:87 [inline]
      raw_notifier_call_chain+0x53/0xb0 kernel/notifier.c:455
      __dev_notify_flags+0x1d6/0x3a0
      dev_change_flags+0xa2/0xc0 net/core/dev.c:8607
      do_setlink+0x778/0x2230 net/core/rtnetlink.c:2780
      __rtnl_newlink net/core/rtnetlink.c:3546 [inline]
      rtnl_newlink+0x114c/0x16a0 net/core/rtnetlink.c:3593
      rtnetlink_rcv_msg+0x811/0x8c0 net/core/rtnetlink.c:6089
      netlink_rcv_skb+0x13e/0x240 net/netlink/af_netlink.c:2501
      rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6107
      netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
      netlink_unicast+0x58a/0x660 net/netlink/af_netlink.c:1345
      netlink_sendmsg+0x661/0x750 net/netlink/af_netlink.c:1921
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg net/socket.c:734 [inline]
      __sys_sendto+0x21e/0x2c0 net/socket.c:2119
      __do_sys_sendto net/socket.c:2131 [inline]
      __se_sys_sendto net/socket.c:2127 [inline]
      __x64_sys_sendto+0x74/0x90 net/socket.c:2127
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      read to 0xffff888144ecf518 of 1 bytes by task 20423 on cpu 1:
      dev_isalive net/core/net-sysfs.c:38 [inline]
      netdev_show net/core/net-sysfs.c:50 [inline]
      type_show+0x24/0x90 net/core/net-sysfs.c:112
      dev_attr_show+0x35/0x90 drivers/base/core.c:2095
      sysfs_kf_seq_show+0x175/0x240 fs/sysfs/file.c:59
      kernfs_seq_show+0x75/0x80 fs/kernfs/file.c:162
      seq_read_iter+0x2c3/0x8e0 fs/seq_file.c:230
      kernfs_fop_read_iter+0xd1/0x2f0 fs/kernfs/file.c:235
      call_read_iter include/linux/fs.h:2052 [inline]
      new_sync_read fs/read_write.c:401 [inline]
      vfs_read+0x5a5/0x6a0 fs/read_write.c:482
      ksys_read+0xe8/0x1a0 fs/read_write.c:620
      __do_sys_read fs/read_write.c:630 [inline]
      __se_sys_read fs/read_write.c:628 [inline]
      __x64_sys_read+0x3e/0x50 fs/read_write.c:628
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      value changed: 0x00 -> 0x01
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 20423 Comm: udevd Tainted: G W 5.19.0-rc2-syzkaller-dirty #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc26c266
    • C
      phy: aquantia: Fix AN when higher speeds than 1G are not advertised · 9b7fd167
      Claudiu Manoil 提交于
      Even when the eth port is resticted to work with speeds not higher than 1G,
      and so the eth driver is requesting the phy (via phylink) to advertise up
      to 1000BASET support, the aquantia phy device is still advertising for 2.5G
      and 5G speeds.
      Clear these advertising defaults when requested.
      
      Cc: Ondrej Spacek <ondrej.spacek@nxp.com>
      Fixes: 09c4c57f ("net: phy: aquantia: add support for auto-negotiation configuration")
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Link: https://lore.kernel.org/r/20220610084037.7625-1-claudiu.manoil@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      9b7fd167
    • A
      Merge branch 'bpf: Fix cookie values for kprobe multi' · a4a8b2ee
      Alexei Starovoitov 提交于
      Jiri Olsa says:
      
      ====================
      
      hi,
      there's bug in kprobe_multi link that makes cookies misplaced when
      using symbols to attach. The reason is that we sort symbols by name
      but not adjacent cookie values. Current test did not find it because
      bpf_fentry_test* are already sorted by name.
      
      v3 changes:
        - fixed kprobe_multi bench test to filter out invalid entries
          from available_filter_functions
      
      v2 changes:
        - rebased on top of bpf/master
        - checking if cookies are defined later in swap function [Andrii]
        - added acks
      
      thanks,
      jirka
      ====================
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      a4a8b2ee