Skip to content
Snippets Groups Projects
  1. Jun 23, 2022
  2. Jun 22, 2022
  3. Jun 21, 2022
  4. Jun 20, 2022
    • Ziyang Xuan's avatar
      net/tls: fix tls_sk_proto_close executed repeatedly · 69135c57
      Ziyang Xuan authored
      
      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: default avatar <syzbot+29c3c12f3214b85ad081@syzkaller.appspotmail.com>
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69135c57
    • Eric Dumazet's avatar
      erspan: do not assume transport header is always set · 301bd140
      Eric Dumazet authored
      
      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-g274295c6e53f #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: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: William Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      301bd140
    • Riccardo Paolo Bestetti's avatar
      ipv4: fix bind address validity regression tests · 313c502f
      Riccardo Paolo Bestetti authored
      
      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: default avatarRiccardo Paolo Bestetti <pbl@bestov.io>
      Signed-off-by: default avatarRiccardo Paolo Bestetti <pbl@bestov.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      313c502f
  5. Jun 19, 2022
    • Oleksij Rempel's avatar
      net: phy: at803x: fix NULL pointer dereference on AR9331 PHY · 9926de73
      Oleksij Rempel authored
      
      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: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9926de73
    • Wentao_Liang's avatar
      drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c · 8fc74d18
      Wentao_Liang authored
      
      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: default avatarWentao_Liang <Wentao_Liang_g@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8fc74d18
  6. Jun 18, 2022
    • Peilin Ye's avatar
      net/sched: sch_netem: Fix arithmetic in netem_dump() for 32-bit platforms · a2b1a5d4
      Peilin Ye authored
      As reported by Yuming, currently tc always show a latency of UINT_MAX
      for netem Qdisc's on 32-bit platforms:
      
          $ tc qdisc add dev dummy0 root netem latency 100ms
          $ tc qdisc show dev dummy0
          qdisc netem 8001: root refcnt 2 limit 1000 delay 275s  275s
                                                     ^^^^^^^^^^^^^^^^
      
      Let us take a closer look at netem_dump():
      
              qopt.latency = min_t(psched_tdiff_t, PSCHED_NS2TICKS(q->latency,
                                   UINT_MAX);
      
      qopt.latency is __u32, psched_tdiff_t is signed long,
      (psched_tdiff_t)(UINT_MAX) is negative for 32-bit platforms, so
      qopt.latency is always UINT_MAX.
      
      Fix it by using psched_time_t (u64) instead.
      
      Note: confusingly, users have two ways to specify 'latency':
      
        1. normally, via '__u32 latency' in struct tc_netem_qopt;
        2. via the TCA_NETEM_LATENCY64 attribute, which is s64.
      
      For the second case, theoretically 'latency' could be negative.  This
      patch ignores that corner case, since it is broken (i.e. assigning a
      negative s64 to __u32) anyways, and should be handled separately.
      
      Thanks Ted Lin for the analysis [1] .
      
      [1] https://github.com/raspberrypi/linux/issues/3512
      
      
      
      Reported-by: default avatarYuming Chen <chenyuming.junnan@bytedance.com>
      Fixes: 112f9cb6 ("netem: convert to qdisc_watchdog_schedule_ns")
      Reviewed-by: default avatarCong Wang <cong.wang@bytedance.com>
      Signed-off-by: default avatarPeilin Ye <peilin.ye@bytedance.com>
      Acked-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Link: https://lore.kernel.org/r/20220616234336.2443-1-yepeilin.cs@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a2b1a5d4
    • Ivan Vecera's avatar
      ethtool: Fix get module eeprom fallback · a3bb7b63
      Ivan Vecera authored
      
      Function fallback_set_params() checks if the module type returned
      by a driver is ETH_MODULE_SFF_8079 and in this case it assumes
      that buffer returns a concatenated content of page  A0h and A2h.
      The check is wrong because the correct type is ETH_MODULE_SFF_8472.
      
      Fixes: 96d971e3 ("ethtool: Add fallback to get_module_eeprom from netlink command")
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://lore.kernel.org/r/20220616160856.3623273-1-ivecera@redhat.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a3bb7b63
    • Jay Vosburgh's avatar
      bonding: ARP monitor spams NETDEV_NOTIFY_PEERS notifiers · 7a9214f3
      Jay Vosburgh authored
      
      The bonding ARP monitor fails to decrement send_peer_notif, the
      number of peer notifications (gratuitous ARP or ND) to be sent. This
      results in a continuous series of notifications.
      
      Correct this by decrementing the counter for each notification.
      
      Reported-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: b0929915 ("bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for ab arp monitor")
      Link: https://lore.kernel.org/netdev/b2fd4147-8f50-bebd-963a-1a3e8d1d9715@redhat.com/
      
      
      Tested-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Reviewed-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Link: https://lore.kernel.org/r/9400.1655407960@famine
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7a9214f3
    • Lorenzo Bianconi's avatar
      igb: fix a use-after-free issue in igb_clean_tx_ring · 3f6a57ee
      Lorenzo Bianconi authored
      
      Fix the following use-after-free bug in igb_clean_tx_ring routine when
      the NIC is running in XDP mode. The issue can be triggered redirecting
      traffic into the igb NIC and then closing the device while the traffic
      is flowing.
      
      [   73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9
      [   73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017
      [   73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0
      [   73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282
      [   73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000
      [   73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0
      [   73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058
      [   73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090
      [   73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000
      [   73.404806] FS:  00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000
      [   73.413129] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0
      [   73.426565] Call Trace:
      [   73.429087]  <TASK>
      [   73.431314]  igb_clean_tx_ring+0x43/0x140 [igb]
      [   73.436002]  igb_down+0x1d7/0x220 [igb]
      [   73.439974]  __igb_close+0x3c/0x120 [igb]
      [   73.444118]  igb_xdp+0x10c/0x150 [igb]
      [   73.447983]  ? igb_pci_sriov_configure+0x70/0x70 [igb]
      [   73.453362]  dev_xdp_install+0xda/0x110
      [   73.457371]  dev_xdp_attach+0x1da/0x550
      [   73.461369]  do_setlink+0xfd0/0x10f0
      [   73.465166]  ? __nla_validate_parse+0x89/0xc70
      [   73.469714]  rtnl_setlink+0x11a/0x1e0
      [   73.473547]  rtnetlink_rcv_msg+0x145/0x3d0
      [   73.477709]  ? rtnl_calcit.isra.0+0x130/0x130
      [   73.482258]  netlink_rcv_skb+0x8d/0x110
      [   73.486229]  netlink_unicast+0x230/0x340
      [   73.490317]  netlink_sendmsg+0x215/0x470
      [   73.494395]  __sys_sendto+0x179/0x190
      [   73.498268]  ? move_addr_to_user+0x37/0x70
      [   73.502547]  ? __sys_getsockname+0x84/0xe0
      [   73.506853]  ? netlink_setsockopt+0x1c1/0x4a0
      [   73.511349]  ? __sys_setsockopt+0xc8/0x1d0
      [   73.515636]  __x64_sys_sendto+0x20/0x30
      [   73.519603]  do_syscall_64+0x3b/0x80
      [   73.523399]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [   73.528712] RIP: 0033:0x7ff38d41f20c
      [   73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [   73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c
      [   73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003
      [   73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
      [   73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0
      [   73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30
      [   73.596545]  </TASK>
      [   73.598842] ---[ end trace 0000000000000000 ]---
      
      Fixes: 9cbc948b ("igb: add XDP support")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Link: https://lore.kernel.org/r/e5c01d549dc37bff18e46aeabd6fb28a7bcf84be.1655388571.git.lorenzo@kernel.org
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3f6a57ee
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 582573f1
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2022-06-17
      
      We've added 12 non-merge commits during the last 4 day(s) which contain
      a total of 14 files changed, 305 insertions(+), 107 deletions(-).
      
      The main changes are:
      
      1) Fix x86 JIT tailcall count offset on BPF-2-BPF call, from Jakub Sitnicki.
      
      2) Fix a kprobe_multi link bug which misplaces BPF cookies, from Jiri Olsa.
      
      3) Fix an infinite loop when processing a module's BTF, from Kumar Kartikeya Dwivedi.
      
      4) Fix getting a rethook only in RCU available context, from Masami Hiramatsu.
      
      5) Fix request socket refcount leak in sk lookup helpers, from Jon Maxwell.
      
      6) Fix xsk xmit behavior which wrongly adds skb to already full cq, from Ciara Loftus.
      
      * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        rethook: Reject getting a rethook if RCU is not watching
        fprobe, samples: Add use_trace option and show hit/missed counter
        bpf, docs: Update some of the JIT/maintenance entries
        selftest/bpf: Fix kprobe_multi bench test
        bpf: Force cookies array to follow symbols sorting
        ftrace: Keep address offset in ftrace_lookup_symbols
        selftests/bpf: Shuffle cookies symbols in kprobe multi test
        selftests/bpf: Test tail call counting with bpf2bpf and data on stack
        bpf, x86: Fix tail call count offset calculation on bpf2bpf call
        bpf: Limit maximum modifier chain length in btf_check_type_tags
        bpf: Fix request_sock leak in sk lookup helpers
        xsk: Fix generic transmit when completion queue reservation fails
      ====================
      
      Link: https://lore.kernel.org/r/20220617202119.2421-1-daniel@iogearbox.net
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      582573f1
  7. Jun 17, 2022
  8. Jun 16, 2022
    • Jakub Sitnicki's avatar
      selftests/bpf: Test tail call counting with bpf2bpf and data on stack · 5e0b0a4c
      Jakub Sitnicki authored
      
      Cover the case when tail call count needs to be passed from BPF function to
      BPF function, and the caller has data on stack. Specifically when the size
      of data allocated on BPF stack is not a multiple on 8.
      
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20220616162037.535469-3-jakub@cloudflare.com
      5e0b0a4c
    • Jakub Sitnicki's avatar
      bpf, x86: Fix tail call count offset calculation on bpf2bpf call · ff672c67
      Jakub Sitnicki authored
      
      On x86-64 the tail call count is passed from one BPF function to another
      through %rax. Additionally, on function entry, the tail call count value
      is stored on stack right after the BPF program stack, due to register
      shortage.
      
      The stored count is later loaded from stack either when performing a tail
      call - to check if we have not reached the tail call limit - or before
      calling another BPF function call in order to pass it via %rax.
      
      In the latter case, we miscalculate the offset at which the tail call count
      was stored on function entry. The JIT does not take into account that the
      allocated BPF program stack is always a multiple of 8 on x86, while the
      actual stack depth does not have to be.
      
      This leads to a load from an offset that belongs to the BPF stack, as shown
      in the example below:
      
      SEC("tc")
      int entry(struct __sk_buff *skb)
      {
      	/* Have data on stack which size is not a multiple of 8 */
      	volatile char arr[1] = {};
      	return subprog_tail(skb);
      }
      
      int entry(struct __sk_buff * skb):
         0: (b4) w2 = 0
         1: (73) *(u8 *)(r10 -1) = r2
         2: (85) call pc+1#bpf_prog_ce2f79bb5f3e06dd_F
         3: (95) exit
      
      int entry(struct __sk_buff * skb):
         0xffffffffa0201788:  nop    DWORD PTR [rax+rax*1+0x0]
         0xffffffffa020178d:  xor    eax,eax
         0xffffffffa020178f:  push   rbp
         0xffffffffa0201790:  mov    rbp,rsp
         0xffffffffa0201793:  sub    rsp,0x8
         0xffffffffa020179a:  push   rax
         0xffffffffa020179b:  xor    esi,esi
         0xffffffffa020179d:  mov    BYTE PTR [rbp-0x1],sil
         0xffffffffa02017a1:  mov    rax,QWORD PTR [rbp-0x9]	!!! tail call count
         0xffffffffa02017a8:  call   0xffffffffa02017d8       !!! is at rbp-0x10
         0xffffffffa02017ad:  leave
         0xffffffffa02017ae:  ret
      
      Fix it by rounding up the BPF stack depth to a multiple of 8, when
      calculating the tail call count offset on stack.
      
      Fixes: ebf7d1f5 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20220616162037.535469-2-jakub@cloudflare.com
      ff672c67
    • Linus Torvalds's avatar
      Merge tag 'net-5.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 48a23ec6
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Mostly driver fixes.
      
        Current release - regressions:
      
         - Revert "net: Add a second bind table hashed by port and address",
           needs more work
      
         - amd-xgbe: use platform_irq_count(), static setup of IRQ resources
           had been removed from DT core
      
         - dts: at91: ksz9477_evb: add phy-mode to fix port/phy validation
      
        Current release - new code bugs:
      
         - hns3: modify the ring param print info
      
        Previous releases - always broken:
      
         - axienet: make the 64b addressable DMA depends on 64b architectures
      
         - iavf: fix issue with MAC address of VF shown as zero
      
         - ice: fix PTP TX timestamp offset calculation
      
         - usb: ax88179_178a needs FLAG_SEND_ZLP
      
        Misc:
      
         - document some net.sctp.* sysctls"
      
      * tag 'net-5.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (31 commits)
        net: axienet: add missing error return code in axienet_probe()
        Revert "net: Add a second bind table hashed by port and address"
        net: ax25: Fix deadlock caused by skb_recv_datagram in ax25_recvmsg
        net: usb: ax88179_178a needs FLAG_SEND_ZLP
        MAINTAINERS: add include/dt-bindings/net to NETWORKING DRIVERS
        ARM: dts: at91: ksz9477_evb: fix port/phy validation
        net: bgmac: Fix an erroneous kfree() in bgmac_remove()
        ice: Fix memory corruption in VF driver
        ice: Fix queue config fail handling
        ice: Sync VLAN filtering features for DVM
        ice: Fix PTP TX timestamp offset calculation
        mlxsw: spectrum_cnt: Reorder counter pools
        docs: networking: phy: Fix a typo
        amd-xgbe: Use platform_irq_count()
        octeontx2-vf: Add support for adaptive interrupt coalescing
        xilinx:  Fix build on x86.
        net: axienet: Use iowrite64 to write all 64b descriptor pointers
        net: axienet: make the 64b addresable DMA depends on 64b archectures
        net: hns3: fix tm port shapping of fibre port is incorrect after driver initialization
        net: hns3: fix PF rss size initialization bug
        ...
      48a23ec6
    • Yang Yingliang's avatar
      net: axienet: add missing error return code in axienet_probe() · 2e7bf4a6
      Yang Yingliang authored
      
      It should return error code in error path in axienet_probe().
      
      Fixes: 00be43a7 ("net: axienet: make the 64b addresable DMA depends on 64b archectures")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Link: https://lore.kernel.org/r/20220616062917.3601-1-yangyingliang@huawei.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2e7bf4a6
Loading