1. 13 Oct, 2023 1 commit
    • Eric Dumazet's avatar
      xfrm: fix a data-race in xfrm_lookup_with_ifid() · de5724ca
      Eric Dumazet authored
      syzbot complains about a race in xfrm_lookup_with_ifid() [1]
      
      When preparing commit 0a9e5794 ("xfrm: annotate data-race
      around use_time") I thought xfrm_lookup_with_ifid() was modifying
      a still private structure.
      
      [1]
      BUG: KCSAN: data-race in xfrm_lookup_with_ifid / xfrm_lookup_with_ifid
      
      write to 0xffff88813ea41108 of 8 bytes by task 8150 on cpu 1:
      xfrm_lookup_with_ifid+0xce7/0x12d0 net/xfrm/xfrm_policy.c:3218
      xfrm_lookup net/xfrm/xfrm_policy.c:3270 [inline]
      xfrm_lookup_route+0x3b/0x100 net/xfrm/xfrm_policy.c:3281
      ip6_dst_lookup_flow+0x98/0xc0 net/ipv6/ip6_output.c:1246
      send6+0x241/0x3c0 drivers/net/wireguard/socket.c:139
      wg_socket_send_skb_to_peer+0xbd/0x130 drivers/net/wireguard/socket.c:178
      wg_socket_send_buffer_to_peer+0xd6/0x100 drivers/net/wireguard/socket.c:200
      wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline]
      wg_packet_handshake_send_worker+0x10c/0x150 drivers/net/wireguard/send.c:51
      process_one_work kernel/workqueue.c:2630 [inline]
      process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
      worker_thread+0x525/0x730 kernel/workqueue.c:2784
      kthread+0x1d7/0x210 kernel/kthread.c:388
      ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
      
      write to 0xffff88813ea41108 of 8 bytes by task 15867 on cpu 0:
      xfrm_lookup_with_ifid+0xce7/0x12d0 net/xfrm/xfrm_policy.c:3218
      xfrm_lookup net/xfrm/xfrm_policy.c:3270 [inline]
      xfrm_lookup_route+0x3b/0x100 net/xfrm/xfrm_policy.c:3281
      ip6_dst_lookup_flow+0x98/0xc0 net/ipv6/ip6_output.c:1246
      send6+0x241/0x3c0 drivers/net/wireguard/socket.c:139
      wg_socket_send_skb_to_peer+0xbd/0x130 drivers/net/wireguard/socket.c:178
      wg_socket_send_buffer_to_peer+0xd6/0x100 drivers/net/wireguard/socket.c:200
      wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline]
      wg_packet_handshake_send_worker+0x10c/0x150 drivers/net/wireguard/send.c:51
      process_one_work kernel/workqueue.c:2630 [inline]
      process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
      worker_thread+0x525/0x730 kernel/workqueue.c:2784
      kthread+0x1d7/0x210 kernel/kthread.c:388
      ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
      
      value changed: 0x00000000651cd9d1 -> 0x00000000651cd9d2
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 15867 Comm: kworker/u4:58 Not tainted 6.6.0-rc4-syzkaller-00016-g5e62ed3b #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
      Workqueue: wg-kex-wg2 wg_packet_handshake_send_worker
      
      Fixes: 0a9e5794 ("xfrm: annotate data-race around use_time")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      de5724ca
  2. 10 Oct, 2023 2 commits
  3. 20 Sep, 2023 1 commit
    • Zhang Changzhong's avatar
      xfrm6: fix inet6_dev refcount underflow problem · cc9b364b
      Zhang Changzhong authored
      There are race conditions that may lead to inet6_dev refcount underflow
      in xfrm6_dst_destroy() and rt6_uncached_list_flush_dev().
      
      One of the refcount underflow bugs is shown below:
      	(cpu 1)                	|	(cpu 2)
      xfrm6_dst_destroy()             |
        ...                           |
        in6_dev_put()                 |
      				|  rt6_uncached_list_flush_dev()
        ...				|    ...
      				|    in6_dev_put()
        rt6_uncached_list_del()       |    ...
        ...                           |
      
      xfrm6_dst_destroy() calls rt6_uncached_list_del() after in6_dev_put(),
      so rt6_uncached_list_flush_dev() has a chance to call in6_dev_put()
      again for the same inet6_dev.
      
      Fix it by moving in6_dev_put() after rt6_uncached_list_del() in
      xfrm6_dst_destroy().
      
      Fixes: 510c321b ("xfrm: reuse uncached_list to track xdsts")
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      cc9b364b
  4. 13 Sep, 2023 1 commit
    • Eric Dumazet's avatar
      xfrm: fix a data-race in xfrm_gen_index() · 3e4bc239
      Eric Dumazet authored
      xfrm_gen_index() mutual exclusion uses net->xfrm.xfrm_policy_lock.
      
      This means we must use a per-netns idx_generator variable,
      instead of a static one.
      Alternative would be to use an atomic variable.
      
      syzbot reported:
      
      BUG: KCSAN: data-race in xfrm_sk_policy_insert / xfrm_sk_policy_insert
      
      write to 0xffffffff87005938 of 4 bytes by task 29466 on cpu 0:
      xfrm_gen_index net/xfrm/xfrm_policy.c:1385 [inline]
      xfrm_sk_policy_insert+0x262/0x640 net/xfrm/xfrm_policy.c:2347
      xfrm_user_policy+0x413/0x540 net/xfrm/xfrm_state.c:2639
      do_ipv6_setsockopt+0x1317/0x2ce0 net/ipv6/ipv6_sockglue.c:943
      ipv6_setsockopt+0x57/0x130 net/ipv6/ipv6_sockglue.c:1012
      rawv6_setsockopt+0x21e/0x410 net/ipv6/raw.c:1054
      sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
      __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
      __do_sys_setsockopt net/socket.c:2274 [inline]
      __se_sys_setsockopt net/socket.c:2271 [inline]
      __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      read to 0xffffffff87005938 of 4 bytes by task 29460 on cpu 1:
      xfrm_sk_policy_insert+0x13e/0x640
      xfrm_user_policy+0x413/0x540 net/xfrm/xfrm_state.c:2639
      do_ipv6_setsockopt+0x1317/0x2ce0 net/ipv6/ipv6_sockglue.c:943
      ipv6_setsockopt+0x57/0x130 net/ipv6/ipv6_sockglue.c:1012
      rawv6_setsockopt+0x21e/0x410 net/ipv6/raw.c:1054
      sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
      __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
      __do_sys_setsockopt net/socket.c:2274 [inline]
      __se_sys_setsockopt net/socket.c:2271 [inline]
      __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      value changed: 0x00006ad8 -> 0x00006b18
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 29460 Comm: syz-executor.1 Not tainted 6.5.0-rc5-syzkaller-00243-g9106536c #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
      
      Fixes: 1121994c ("netns xfrm: policy insertion in netns")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      3e4bc239
  5. 06 Sep, 2023 1 commit
    • Eric Dumazet's avatar
      xfrm: interface: use DEV_STATS_INC() · f7c4e3e5
      Eric Dumazet authored
      syzbot/KCSAN reported data-races in xfrm whenever dev->stats fields
      are updated.
      
      It appears all of these updates can happen from multiple cpus.
      
      Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
      
      BUG: KCSAN: data-race in xfrmi_xmit / xfrmi_xmit
      
      read-write to 0xffff88813726b160 of 8 bytes by task 23986 on cpu 1:
      xfrmi_xmit+0x74e/0xb20 net/xfrm/xfrm_interface_core.c:583
      __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
      netdev_start_xmit include/linux/netdevice.h:4903 [inline]
      xmit_one net/core/dev.c:3544 [inline]
      dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560
      __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340
      dev_queue_xmit include/linux/netdevice.h:3082 [inline]
      neigh_connected_output+0x231/0x2a0 net/core/neighbour.c:1581
      neigh_output include/net/neighbour.h:542 [inline]
      ip_finish_output2+0x74a/0x850 net/ipv4/ip_output.c:230
      ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:318
      NF_HOOK_COND include/linux/netfilter.h:293 [inline]
      ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:432
      dst_output include/net/dst.h:458 [inline]
      ip_local_out net/ipv4/ip_output.c:127 [inline]
      ip_send_skb+0x72/0xe0 net/ipv4/ip_output.c:1487
      udp_send_skb+0x6a4/0x990 net/ipv4/udp.c:963
      udp_sendmsg+0x1249/0x12d0 net/ipv4/udp.c:1246
      inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:840
      sock_sendmsg_nosec net/socket.c:730 [inline]
      sock_sendmsg net/socket.c:753 [inline]
      ____sys_sendmsg+0x37c/0x4d0 net/socket.c:2540
      ___sys_sendmsg net/socket.c:2594 [inline]
      __sys_sendmmsg+0x269/0x500 net/socket.c:2680
      __do_sys_sendmmsg net/socket.c:2709 [inline]
      __se_sys_sendmmsg net/socket.c:2706 [inline]
      __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2706
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      read-write to 0xffff88813726b160 of 8 bytes by task 23987 on cpu 0:
      xfrmi_xmit+0x74e/0xb20 net/xfrm/xfrm_interface_core.c:583
      __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
      netdev_start_xmit include/linux/netdevice.h:4903 [inline]
      xmit_one net/core/dev.c:3544 [inline]
      dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560
      __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340
      dev_queue_xmit include/linux/netdevice.h:3082 [inline]
      neigh_connected_output+0x231/0x2a0 net/core/neighbour.c:1581
      neigh_output include/net/neighbour.h:542 [inline]
      ip_finish_output2+0x74a/0x850 net/ipv4/ip_output.c:230
      ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:318
      NF_HOOK_COND include/linux/netfilter.h:293 [inline]
      ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:432
      dst_output include/net/dst.h:458 [inline]
      ip_local_out net/ipv4/ip_output.c:127 [inline]
      ip_send_skb+0x72/0xe0 net/ipv4/ip_output.c:1487
      udp_send_skb+0x6a4/0x990 net/ipv4/udp.c:963
      udp_sendmsg+0x1249/0x12d0 net/ipv4/udp.c:1246
      inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:840
      sock_sendmsg_nosec net/socket.c:730 [inline]
      sock_sendmsg net/socket.c:753 [inline]
      ____sys_sendmsg+0x37c/0x4d0 net/socket.c:2540
      ___sys_sendmsg net/socket.c:2594 [inline]
      __sys_sendmmsg+0x269/0x500 net/socket.c:2680
      __do_sys_sendmmsg net/socket.c:2709 [inline]
      __se_sys_sendmmsg net/socket.c:2706 [inline]
      __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2706
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      value changed: 0x00000000000010d7 -> 0x00000000000010d8
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 23987 Comm: syz-executor.5 Not tainted 6.5.0-syzkaller-10885-g0468be89 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      f7c4e3e5
  6. 05 Sep, 2023 4 commits
    • Dong Chenchen's avatar
      net: xfrm: skip policies marked as dead while reinserting policies · 6d41d4fe
      Dong Chenchen authored
      BUG: KASAN: slab-use-after-free in xfrm_policy_inexact_list_reinsert+0xb6/0x430
      Read of size 1 at addr ffff8881051f3bf8 by task ip/668
      
      CPU: 2 PID: 668 Comm: ip Not tainted 6.5.0-rc5-00182-g25aa0beb-dirty #64
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x72/0xa0
       print_report+0xd0/0x620
       kasan_report+0xb6/0xf0
       xfrm_policy_inexact_list_reinsert+0xb6/0x430
       xfrm_policy_inexact_insert_node.constprop.0+0x537/0x800
       xfrm_policy_inexact_alloc_chain+0x23f/0x320
       xfrm_policy_inexact_insert+0x6b/0x590
       xfrm_policy_insert+0x3b1/0x480
       xfrm_add_policy+0x23c/0x3c0
       xfrm_user_rcv_msg+0x2d0/0x510
       netlink_rcv_skb+0x10d/0x2d0
       xfrm_netlink_rcv+0x49/0x60
       netlink_unicast+0x3fe/0x540
       netlink_sendmsg+0x528/0x970
       sock_sendmsg+0x14a/0x160
       ____sys_sendmsg+0x4fc/0x580
       ___sys_sendmsg+0xef/0x160
       __sys_sendmsg+0xf7/0x1b0
       do_syscall_64+0x3f/0x90
       entry_SYSCALL_64_after_hwframe+0x73/0xdd
      
      The root cause is:
      
      cpu 0			cpu1
      xfrm_dump_policy
      xfrm_policy_walk
      list_move_tail
      			xfrm_add_policy
      			... ...
      			xfrm_policy_inexact_list_reinsert
      			list_for_each_entry_reverse
      				if (!policy->bydst_reinsert)
      				//read non-existent policy
      xfrm_dump_policy_done
      xfrm_policy_walk_done
      list_del(&walk->walk.all);
      
      If dump_one_policy() returns err (triggered by netlink socket),
      xfrm_policy_walk() will move walk initialized by socket to list
      net->xfrm.policy_all. so this socket becomes visible in the global
      policy list. The head *walk can be traversed when users add policies
      with different prefixlen and trigger xfrm_policy node merge.
      
      The issue can also be triggered by policy list traversal while rehashing
      and flushing policies.
      
      It can be fixed by skip such "policies" with walk.dead set to 1.
      
      Fixes: 9cf545eb ("xfrm: policy: store inexact policies in a tree ordered by destination address")
      Fixes: 12a169e7 ("ipsec: Put dumpers on the dump list")
      Signed-off-by: default avatarDong Chenchen <dongchenchen2@huawei.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      6d41d4fe
    • Sabrina Dubroca's avatar
      Revert "net: macsec: preserve ingress frame ordering" · d3287e40
      Sabrina Dubroca authored
      This reverts commit ab046a5d.
      
      It was trying to work around an issue at the crypto layer by excluding
      ASYNC implementations of gcm(aes), because a bug in the AESNI version
      caused reordering when some requests bypassed the cryptd queue while
      older requests were still pending on the queue.
      
      This was fixed by commit 38b2f68b ("crypto: aesni - Fix cryptd
      reordering problem on gcm"), which pre-dates ab046a5d.
      
      Herbert Xu confirmed that all ASYNC implementations are expected to
      maintain the ordering of completions wrt requests, so we can use them
      in MACsec.
      
      On my test machine, this restores the performance of a single netperf
      instance, from 1.4Gbps to 4.4Gbps.
      
      Link: https://lore.kernel.org/netdev/9328d206c5d9f9239cae27e62e74de40b258471d.1692279161.git.sd@queasysnail.net/T/
      Link: https://lore.kernel.org/netdev/1b0cec71-d084-8153-2ba4-72ce71abeb65@byu.edu/
      Link: https://lore.kernel.org/netdev/d335ddaa-18dc-f9f0-17ee-9783d3b2ca29@mailbox.tu-dresden.de/
      Fixes: ab046a5d ("net: macsec: preserve ingress frame ordering")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Link: https://lore.kernel.org/r/11c952469d114db6fb29242e1d9545e61f52f512.1693757159.git.sd@queasysnail.netSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      d3287e40
    • Shigeru Yoshida's avatar
      kcm: Destroy mutex in kcm_exit_net() · 6ad40b36
      Shigeru Yoshida authored
      kcm_exit_net() should call mutex_destroy() on knet->mutex. This is especially
      needed if CONFIG_DEBUG_MUTEXES is enabled.
      
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Signed-off-by: default avatarShigeru Yoshida <syoshida@redhat.com>
      Link: https://lore.kernel.org/r/20230902170708.1727999-1-syoshida@redhat.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      6ad40b36
    • valis's avatar
      net: sched: sch_qfq: Fix UAF in qfq_dequeue() · 8fc134fe
      valis authored
      When the plug qdisc is used as a class of the qfq qdisc it could trigger a
      UAF. This issue can be reproduced with following commands:
      
        tc qdisc add dev lo root handle 1: qfq
        tc class add dev lo parent 1: classid 1:1 qfq weight 1 maxpkt 512
        tc qdisc add dev lo parent 1:1 handle 2: plug
        tc filter add dev lo parent 1: basic classid 1:1
        ping -c1 127.0.0.1
      
      and boom:
      
      [  285.353793] BUG: KASAN: slab-use-after-free in qfq_dequeue+0xa7/0x7f0
      [  285.354910] Read of size 4 at addr ffff8880bad312a8 by task ping/144
      [  285.355903]
      [  285.356165] CPU: 1 PID: 144 Comm: ping Not tainted 6.5.0-rc3+ #4
      [  285.357112] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
      [  285.358376] Call Trace:
      [  285.358773]  <IRQ>
      [  285.359109]  dump_stack_lvl+0x44/0x60
      [  285.359708]  print_address_description.constprop.0+0x2c/0x3c0
      [  285.360611]  kasan_report+0x10c/0x120
      [  285.361195]  ? qfq_dequeue+0xa7/0x7f0
      [  285.361780]  qfq_dequeue+0xa7/0x7f0
      [  285.362342]  __qdisc_run+0xf1/0x970
      [  285.362903]  net_tx_action+0x28e/0x460
      [  285.363502]  __do_softirq+0x11b/0x3de
      [  285.364097]  do_softirq.part.0+0x72/0x90
      [  285.364721]  </IRQ>
      [  285.365072]  <TASK>
      [  285.365422]  __local_bh_enable_ip+0x77/0x90
      [  285.366079]  __dev_queue_xmit+0x95f/0x1550
      [  285.366732]  ? __pfx_csum_and_copy_from_iter+0x10/0x10
      [  285.367526]  ? __pfx___dev_queue_xmit+0x10/0x10
      [  285.368259]  ? __build_skb_around+0x129/0x190
      [  285.368960]  ? ip_generic_getfrag+0x12c/0x170
      [  285.369653]  ? __pfx_ip_generic_getfrag+0x10/0x10
      [  285.370390]  ? csum_partial+0x8/0x20
      [  285.370961]  ? raw_getfrag+0xe5/0x140
      [  285.371559]  ip_finish_output2+0x539/0xa40
      [  285.372222]  ? __pfx_ip_finish_output2+0x10/0x10
      [  285.372954]  ip_output+0x113/0x1e0
      [  285.373512]  ? __pfx_ip_output+0x10/0x10
      [  285.374130]  ? icmp_out_count+0x49/0x60
      [  285.374739]  ? __pfx_ip_finish_output+0x10/0x10
      [  285.375457]  ip_push_pending_frames+0xf3/0x100
      [  285.376173]  raw_sendmsg+0xef5/0x12d0
      [  285.376760]  ? do_syscall_64+0x40/0x90
      [  285.377359]  ? __static_call_text_end+0x136578/0x136578
      [  285.378173]  ? do_syscall_64+0x40/0x90
      [  285.378772]  ? kasan_enable_current+0x11/0x20
      [  285.379469]  ? __pfx_raw_sendmsg+0x10/0x10
      [  285.380137]  ? __sock_create+0x13e/0x270
      [  285.380673]  ? __sys_socket+0xf3/0x180
      [  285.381174]  ? __x64_sys_socket+0x3d/0x50
      [  285.381725]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      [  285.382425]  ? __rcu_read_unlock+0x48/0x70
      [  285.382975]  ? ip4_datagram_release_cb+0xd8/0x380
      [  285.383608]  ? __pfx_ip4_datagram_release_cb+0x10/0x10
      [  285.384295]  ? preempt_count_sub+0x14/0xc0
      [  285.384844]  ? __list_del_entry_valid+0x76/0x140
      [  285.385467]  ? _raw_spin_lock_bh+0x87/0xe0
      [  285.386014]  ? __pfx__raw_spin_lock_bh+0x10/0x10
      [  285.386645]  ? release_sock+0xa0/0xd0
      [  285.387148]  ? preempt_count_sub+0x14/0xc0
      [  285.387712]  ? freeze_secondary_cpus+0x348/0x3c0
      [  285.388341]  ? aa_sk_perm+0x177/0x390
      [  285.388856]  ? __pfx_aa_sk_perm+0x10/0x10
      [  285.389441]  ? check_stack_object+0x22/0x70
      [  285.390032]  ? inet_send_prepare+0x2f/0x120
      [  285.390603]  ? __pfx_inet_sendmsg+0x10/0x10
      [  285.391172]  sock_sendmsg+0xcc/0xe0
      [  285.391667]  __sys_sendto+0x190/0x230
      [  285.392168]  ? __pfx___sys_sendto+0x10/0x10
      [  285.392727]  ? kvm_clock_get_cycles+0x14/0x30
      [  285.393328]  ? set_normalized_timespec64+0x57/0x70
      [  285.393980]  ? _raw_spin_unlock_irq+0x1b/0x40
      [  285.394578]  ? __x64_sys_clock_gettime+0x11c/0x160
      [  285.395225]  ? __pfx___x64_sys_clock_gettime+0x10/0x10
      [  285.395908]  ? _copy_to_user+0x3e/0x60
      [  285.396432]  ? exit_to_user_mode_prepare+0x1a/0x120
      [  285.397086]  ? syscall_exit_to_user_mode+0x22/0x50
      [  285.397734]  ? do_syscall_64+0x71/0x90
      [  285.398258]  __x64_sys_sendto+0x74/0x90
      [  285.398786]  do_syscall_64+0x64/0x90
      [  285.399273]  ? exit_to_user_mode_prepare+0x1a/0x120
      [  285.399949]  ? syscall_exit_to_user_mode+0x22/0x50
      [  285.400605]  ? do_syscall_64+0x71/0x90
      [  285.401124]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      [  285.401807] RIP: 0033:0x495726
      [  285.402233] Code: ff ff ff f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 09
      [  285.404683] RSP: 002b:00007ffcc25fb618 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [  285.405677] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 0000000000495726
      [  285.406628] RDX: 0000000000000040 RSI: 0000000002518750 RDI: 0000000000000000
      [  285.407565] RBP: 00000000005205ef R08: 00000000005f8838 R09: 000000000000001c
      [  285.408523] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000002517634
      [  285.409460] R13: 00007ffcc25fb6f0 R14: 0000000000000003 R15: 0000000000000000
      [  285.410403]  </TASK>
      [  285.410704]
      [  285.410929] Allocated by task 144:
      [  285.411402]  kasan_save_stack+0x1e/0x40
      [  285.411926]  kasan_set_track+0x21/0x30
      [  285.412442]  __kasan_slab_alloc+0x55/0x70
      [  285.412973]  kmem_cache_alloc_node+0x187/0x3d0
      [  285.413567]  __alloc_skb+0x1b4/0x230
      [  285.414060]  __ip_append_data+0x17f7/0x1b60
      [  285.414633]  ip_append_data+0x97/0xf0
      [  285.415144]  raw_sendmsg+0x5a8/0x12d0
      [  285.415640]  sock_sendmsg+0xcc/0xe0
      [  285.416117]  __sys_sendto+0x190/0x230
      [  285.416626]  __x64_sys_sendto+0x74/0x90
      [  285.417145]  do_syscall_64+0x64/0x90
      [  285.417624]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      [  285.418306]
      [  285.418531] Freed by task 144:
      [  285.418960]  kasan_save_stack+0x1e/0x40
      [  285.419469]  kasan_set_track+0x21/0x30
      [  285.419988]  kasan_save_free_info+0x27/0x40
      [  285.420556]  ____kasan_slab_free+0x109/0x1a0
      [  285.421146]  kmem_cache_free+0x1c2/0x450
      [  285.421680]  __netif_receive_skb_core+0x2ce/0x1870
      [  285.422333]  __netif_receive_skb_one_core+0x97/0x140
      [  285.423003]  process_backlog+0x100/0x2f0
      [  285.423537]  __napi_poll+0x5c/0x2d0
      [  285.424023]  net_rx_action+0x2be/0x560
      [  285.424510]  __do_softirq+0x11b/0x3de
      [  285.425034]
      [  285.425254] The buggy address belongs to the object at ffff8880bad31280
      [  285.425254]  which belongs to the cache skbuff_head_cache of size 224
      [  285.426993] The buggy address is located 40 bytes inside of
      [  285.426993]  freed 224-byte region [ffff8880bad31280, ffff8880bad31360)
      [  285.428572]
      [  285.428798] The buggy address belongs to the physical page:
      [  285.429540] page:00000000f4b77674 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbad31
      [  285.430758] flags: 0x100000000000200(slab|node=0|zone=1)
      [  285.431447] page_type: 0xffffffff()
      [  285.431934] raw: 0100000000000200 ffff88810094a8c0 dead000000000122 0000000000000000
      [  285.432757] raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
      [  285.433562] page dumped because: kasan: bad access detected
      [  285.434144]
      [  285.434320] Memory state around the buggy address:
      [  285.434828]  ffff8880bad31180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  285.435580]  ffff8880bad31200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  285.436264] >ffff8880bad31280: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  285.436777]                                   ^
      [  285.437106]  ffff8880bad31300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
      [  285.437616]  ffff8880bad31380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  285.438126] ==================================================================
      [  285.438662] Disabling lock debugging due to kernel taint
      
      Fix this by:
      1. Changing sch_plug's .peek handler to qdisc_peek_dequeued(), a
      function compatible with non-work-conserving qdiscs
      2. Checking the return value of qdisc_dequeue_peeked() in sch_qfq.
      
      Fixes: 462dbc91 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
      Reported-by: default avatarvalis <sec@valis.email>
      Signed-off-by: default avatarvalis <sec@valis.email>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Link: https://lore.kernel.org/r/20230901162237.11525-1-jhs@mojatatu.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      8fc134fe
  7. 04 Sep, 2023 13 commits
    • David S. Miller's avatar
      Merge branch 'af_unix-data-races' · 2861f09c
      David S. Miller authored
      Kuniyuki Iwashima says:
      
      ====================
      af_unix: Fix four data-races.
      
      While running syzkaller, KCSAN reported 3 data-races with
      systemd-coredump using AF_UNIX sockets.
      
      This series fixes the three and another one inspiered by
      one of the reports.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2861f09c
    • Kuniyuki Iwashima's avatar
      af_unix: Fix data race around sk->sk_err. · b1928129
      Kuniyuki Iwashima authored
      As with sk->sk_shutdown shown in the previous patch, sk->sk_err can be
      read locklessly by unix_dgram_sendmsg().
      
      Let's use READ_ONCE() for sk_err as well.
      
      Note that the writer side is marked by commit cc04410a ("af_unix:
      annotate lockless accesses to sk->sk_err").
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1928129
    • Kuniyuki Iwashima's avatar
      af_unix: Fix data-races around sk->sk_shutdown. · afe8764f
      Kuniyuki Iwashima authored
      sk->sk_shutdown is changed under unix_state_lock(sk), but
      unix_dgram_sendmsg() calls two functions to read sk_shutdown locklessly.
      
        sock_alloc_send_pskb
        `- sock_wait_for_wmem
      
      Let's use READ_ONCE() there.
      
      Note that the writer side was marked by commit e1d09c2c ("af_unix:
      Fix data races around sk->sk_shutdown.").
      
      BUG: KCSAN: data-race in sock_alloc_send_pskb / unix_release_sock
      
      write (marked) to 0xffff8880069af12c of 1 bytes by task 1 on cpu 1:
       unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631
       unix_release+0x59/0x80 net/unix/af_unix.c:1053
       __sock_release+0x7d/0x170 net/socket.c:654
       sock_close+0x19/0x30 net/socket.c:1386
       __fput+0x2a3/0x680 fs/file_table.c:384
       ____fput+0x15/0x20 fs/file_table.c:412
       task_work_run+0x116/0x1a0 kernel/task_work.c:179
       resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
       exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204
       __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
       syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297
       do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      
      read to 0xffff8880069af12c of 1 bytes by task 28650 on cpu 0:
       sock_alloc_send_pskb+0xd2/0x620 net/core/sock.c:2767
       unix_dgram_sendmsg+0x2f8/0x14f0 net/unix/af_unix.c:1944
       unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
       unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
       sock_sendmsg_nosec net/socket.c:725 [inline]
       sock_sendmsg+0x148/0x160 net/socket.c:748
       ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
       ___sys_sendmsg+0xc6/0x140 net/socket.c:2548
       __sys_sendmsg+0x94/0x140 net/socket.c:2577
       __do_sys_sendmsg net/socket.c:2586 [inline]
       __se_sys_sendmsg net/socket.c:2584 [inline]
       __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      
      value changed: 0x00 -> 0x03
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 28650 Comm: systemd-coredum Not tainted 6.4.0-11989-g68433066 #6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afe8764f
    • Kuniyuki Iwashima's avatar
      af_unix: Fix data-race around unix_tot_inflight. · ade32bd8
      Kuniyuki Iwashima authored
      unix_tot_inflight is changed under spin_lock(unix_gc_lock), but
      unix_release_sock() reads it locklessly.
      
      Let's use READ_ONCE() for unix_tot_inflight.
      
      Note that the writer side was marked by commit 9d6d7f1c ("af_unix:
      annote lockless accesses to unix_tot_inflight & gc_in_progress")
      
      BUG: KCSAN: data-race in unix_inflight / unix_release_sock
      
      write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:
       unix_inflight+0x130/0x180 net/unix/scm.c:64
       unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123
       unix_scm_to_skb net/unix/af_unix.c:1832 [inline]
       unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955
       sock_sendmsg_nosec net/socket.c:724 [inline]
       sock_sendmsg+0x148/0x160 net/socket.c:747
       ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493
       ___sys_sendmsg+0xc6/0x140 net/socket.c:2547
       __sys_sendmsg+0x94/0x140 net/socket.c:2576
       __do_sys_sendmsg net/socket.c:2585 [inline]
       __se_sys_sendmsg net/socket.c:2583 [inline]
       __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:
       unix_release_sock+0x608/0x910 net/unix/af_unix.c:671
       unix_release+0x59/0x80 net/unix/af_unix.c:1058
       __sock_release+0x7d/0x170 net/socket.c:653
       sock_close+0x19/0x30 net/socket.c:1385
       __fput+0x179/0x5e0 fs/file_table.c:321
       ____fput+0x15/0x20 fs/file_table.c:349
       task_work_run+0x116/0x1a0 kernel/task_work.c:179
       resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
       exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204
       __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
       syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297
       do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      value changed: 0x00000000 -> 0x00000001
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      
      Fixes: 9305cfa4 ("[AF_UNIX]: Make unix_tot_inflight counter non-atomic")
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ade32bd8
    • Kuniyuki Iwashima's avatar
      af_unix: Fix data-races around user->unix_inflight. · 0bc36c06
      Kuniyuki Iwashima authored
      user->unix_inflight is changed under spin_lock(unix_gc_lock),
      but too_many_unix_fds() reads it locklessly.
      
      Let's annotate the write/read accesses to user->unix_inflight.
      
      BUG: KCSAN: data-race in unix_attach_fds / unix_inflight
      
      write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:
       unix_inflight+0x157/0x180 net/unix/scm.c:66
       unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123
       unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
       unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
       unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
       unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
       sock_sendmsg_nosec net/socket.c:725 [inline]
       sock_sendmsg+0x148/0x160 net/socket.c:748
       ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
       ___sys_sendmsg+0xc6/0x140 net/socket.c:2548
       __sys_sendmsg+0x94/0x140 net/socket.c:2577
       __do_sys_sendmsg net/socket.c:2586 [inline]
       __se_sys_sendmsg net/socket.c:2584 [inline]
       __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      
      read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:
       too_many_unix_fds net/unix/scm.c:101 [inline]
       unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110
       unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
       unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
       unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
       unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
       sock_sendmsg_nosec net/socket.c:725 [inline]
       sock_sendmsg+0x148/0x160 net/socket.c:748
       ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
       ___sys_sendmsg+0xc6/0x140 net/socket.c:2548
       __sys_sendmsg+0x94/0x140 net/socket.c:2577
       __do_sys_sendmsg net/socket.c:2586 [inline]
       __se_sys_sendmsg net/socket.c:2584 [inline]
       __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      
      value changed: 0x000000000000000c -> 0x000000000000000d
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g68433066 #6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      
      Fixes: 712f4aad ("unix: properly account for FDs passed over unix sockets")
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Acked-by: default avatarWilly Tarreau <w@1wt.eu>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0bc36c06
    • Kuniyuki Iwashima's avatar
      af_unix: Fix msg_controllen test in scm_pidfd_recv() for MSG_CMSG_COMPAT. · 718e6b51
      Kuniyuki Iwashima authored
      Heiko Carstens reported that SCM_PIDFD does not work with MSG_CMSG_COMPAT
      because scm_pidfd_recv() always checks msg_controllen against sizeof(struct
      cmsghdr).
      
      We need to use sizeof(struct compat_cmsghdr) for the compat case.
      
      Fixes: 5e2ff670 ("scm: add SO_PASSPIDFD and SCM_PIDFD")
      Reported-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      Closes: https://lore.kernel.org/netdev/20230901200517.8742-A-hca@linux.ibm.com/Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Tested-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      Reviewed-by: default avatarAlexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
      Reviewed-by: default avatarMichal Swiatkowski <michal.swiatkowski@linux.intel.com>
      Acked-by: default avatarChristian Brauner <brauner@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      718e6b51
    • Jakub Kicinski's avatar
      docs: netdev: update the netdev infra URLs · 52450087
      Jakub Kicinski authored
      Some corporate proxies block our current NIPA URLs because
      they use a free / shady DNS domain. As suggested by Jesse
      we got a new DNS entry from Konstantin - netdev.bots.linux.dev,
      use it.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52450087
    • Jakub Kicinski's avatar
      docs: netdev: document patchwork patch states · ee8ab74a
      Jakub Kicinski authored
      The patchwork states are largely self-explanatory but small
      ambiguities may still come up. Document how we interpret
      the states in networking.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee8ab74a
    • Oleksij Rempel's avatar
      net: phy: micrel: Correct bit assignments for phy_device flags · 719c5e37
      Oleksij Rempel authored
      Previously, the defines for phy_device flags in the Micrel driver were
      ambiguous in their representation. They were intended to be bit masks
      but were mistakenly defined as bit positions. This led to the following
      issues:
      
      - MICREL_KSZ8_P1_ERRATA, designated for KSZ88xx switches, overlapped
        with MICREL_PHY_FXEN and MICREL_PHY_50MHZ_CLK.
      - Due to this overlap, the code path for MICREL_PHY_FXEN, tailored for
        the KSZ8041 PHY, was not executed for KSZ88xx PHYs.
      - Similarly, the code associated with MICREL_PHY_50MHZ_CLK wasn't
        triggered for KSZ88xx.
      
      To rectify this, all three flags have now been explicitly converted to
      use the `BIT()` macro, ensuring they are defined as bit masks and
      preventing potential overlaps in the future.
      
      Fixes: 49011e0c ("net: phy: micrel: ksz886x/ksz8081: add cabletest support")
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      719c5e37
    • Alex Henrie's avatar
      net: ipv6/addrconf: avoid integer underflow in ipv6_create_tempaddr · f31867d0
      Alex Henrie authored
      The existing code incorrectly casted a negative value (the result of a
      subtraction) to an unsigned value without checking. For example, if
      /proc/sys/net/ipv6/conf/*/temp_prefered_lft was set to 1, the preferred
      lifetime would jump to 4 billion seconds. On my machine and network the
      shortest lifetime that avoided underflow was 3 seconds.
      
      Fixes: 76506a98 ("IPv6: fix DESYNC_FACTOR")
      Signed-off-by: default avatarAlex Henrie <alexhenrie24@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f31867d0
    • Liang Chen's avatar
      veth: Fixing transmit return status for dropped packets · 151e887d
      Liang Chen authored
      The veth_xmit function returns NETDEV_TX_OK even when packets are dropped.
      This behavior leads to incorrect calculations of statistics counts, as
      well as things like txq->trans_start updates.
      
      Fixes: e314dbdc ("[NET]: Virtual ethernet device driver.")
      Signed-off-by: default avatarLiang Chen <liangchen.linux@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      151e887d
    • Eric Dumazet's avatar
      gve: fix frag_list chaining · 817c7cd2
      Eric Dumazet authored
      gve_rx_append_frags() is able to build skbs chained with frag_list,
      like GRO engine.
      
      Problem is that shinfo->frag_list should only be used
      for the head of the chain.
      
      All other links should use skb->next pointer.
      
      Otherwise, built skbs are not valid and can cause crashes.
      
      Equivalent code in GRO (skb_gro_receive()) is:
      
          if (NAPI_GRO_CB(p)->last == p)
              skb_shinfo(p)->frag_list = skb;
          else
              NAPI_GRO_CB(p)->last->next = skb;
          NAPI_GRO_CB(p)->last = skb;
      
      Fixes: 9b8dd5e5 ("gve: DQO: Add RX path")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Bailey Forrest <bcf@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Catherine Sullivan <csully@google.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      817c7cd2
    • Eric Dumazet's avatar
      net: deal with integer overflows in kmalloc_reserve() · 915d975b
      Eric Dumazet authored
      Blamed commit changed:
          ptr = kmalloc(size);
          if (ptr)
            size = ksize(ptr);
      
      to:
          size = kmalloc_size_roundup(size);
          ptr = kmalloc(size);
      
      This allowed various crash as reported by syzbot [1]
      and Kyle Zeng.
      
      Problem is that if @size is bigger than 0x80000001,
      kmalloc_size_roundup(size) returns 2^32.
      
      kmalloc_reserve() uses a 32bit variable (obj_size),
      so 2^32 is truncated to 0.
      
      kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
      skb allocations.
      
      Following trace can be triggered if a netdev->mtu is set
      close to 0x7fffffff
      
      We might in the future limit netdev->mtu to more sensible
      limit (like KMALLOC_MAX_SIZE).
      
      This patch is based on a syzbot report, and also a report
      and tentative fix from Kyle Zeng.
      
      [1]
      BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
      BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
      Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554
      
      CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
      Call trace:
      dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
      show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
      print_report+0xe4/0x4b4 mm/kasan/report.c:398
      kasan_report+0x150/0x1ac mm/kasan/report.c:495
      kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
      memset+0x40/0x70 mm/kasan/shadow.c:44
      __build_skb_around net/core/skbuff.c:294 [inline]
      __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
      alloc_skb include/linux/skbuff.h:1316 [inline]
      igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359
      add_grec+0x81c/0x1124 net/ipv4/igmp.c:534
      igmpv3_send_cr net/ipv4/igmp.c:667 [inline]
      igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810
      call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474
      expire_timers kernel/time/timer.c:1519 [inline]
      __run_timers+0x54c/0x710 kernel/time/timer.c:1790
      run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
      _stext+0x380/0xfbc
      ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79
      call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891
      do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84
      invoke_softirq kernel/softirq.c:437 [inline]
      __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683
      irq_exit_rcu+0x14/0x78 kernel/softirq.c:695
      el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717
      __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724
      el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729
      el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
      
      Fixes: 12d6c1d3 ("skbuff: Proactively round up to kmalloc bucket size")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reported-by: default avatarKyle Zeng <zengyhkyle@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      915d975b
  8. 03 Sep, 2023 1 commit
  9. 01 Sep, 2023 14 commits
    • Edward Cree's avatar
      sfc: check for zero length in EF10 RX prefix · ae074e2b
      Edward Cree authored
      When EF10 RXDP firmware is operating in cut-through mode, packet length
       is not known at the time the RX prefix is generated, so it is left as
       zero and RX event merging is inhibited to ensure that the length is
       available in the RX event.  However, it has been found that in certain
       circumstances the RX events for these packets still get merged,
       meaning the driver cannot read the length from the RX event, and tries
       to use the length from the prefix.
      The resulting zero-length SKBs cause crashes in GRO since commit
       1d11fa69 ("net-gro: remove GRO_DROP"), so add a check to the driver
       to detect these zero-length RX events and discard the packet.
      Signed-off-by: default avatarEdward Cree <ecree.xilinx@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae074e2b
    • David S. Miller's avatar
      Merge branch 'dst-hint-multipath' · d8a30706
      David S. Miller authored
      Sriram Yagnaraman says:
      
      ====================
      Avoid TCP resets when using ECMP for load-balancing between multiple servers.
      
      All packets in the same flow (L3/L4 depending on multipath hash policy)
      should be directed to the same target, but after [0]/[1] we see stray
      packets directed towards other targets. This, for instance, causes RST
      to be sent on TCP connections.
      
      The first two patches solve the problem by ignoring route hints for
      destinations that are part of multipath group, by using new SKB flags
      for IPv4 and IPv6. The third patch is a selftest that tests the
      scenario.
      
      Thanks to Ido, for reviewing and suggesting a way forward in [2] and
      also suggesting how to write a selftest for this.
      
      v4->v5:
      - Fixed review comments from Ido
      v3->v4:
      - Remove single path test
      - Rebase to latest
      v2->v3:
      - Add NULL check for skb in fib6_select_path (Ido Schimmel)
      - Use fib_tests.sh for selftest instead of the forwarding suite (Ido
        Schimmel)
      v1->v2:
      - Update to commit messages describing the solution (Ido Schimmel)
      - Use perf stat to count fib table lookups in selftest (Ido Schimmel)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8a30706
    • Sriram Yagnaraman's avatar
      selftests: fib_tests: Add multipath list receive tests · 8ae9efb8
      Sriram Yagnaraman authored
      The test uses perf stat to count the number of fib:fib_table_lookup
      tracepoint hits for IPv4 and the number of fib6:fib6_table_lookup for
      IPv6. The measured count is checked to be within 5% of the total number
      of packets sent via veth1.
      Signed-off-by: default avatarSriram Yagnaraman <sriram.yagnaraman@est.tech>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ae9efb8
    • Sriram Yagnaraman's avatar
      ipv6: ignore dst hint for multipath routes · 8423be89
      Sriram Yagnaraman authored
      Route hints when the nexthop is part of a multipath group causes packets
      in the same receive batch to be sent to the same nexthop irrespective of
      the multipath hash of the packet. So, do not extract route hint for
      packets whose destination is part of a multipath group.
      
      A new SKB flag IP6SKB_MULTIPATH is introduced for this purpose, set the
      flag when route is looked up in fib6_select_path() and use it in
      ip6_can_use_hint() to check for the existence of the flag.
      
      Fixes: 197dbf24 ("ipv6: introduce and uses route look hints for list input.")
      Signed-off-by: default avatarSriram Yagnaraman <sriram.yagnaraman@est.tech>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8423be89
    • Sriram Yagnaraman's avatar
      ipv4: ignore dst hint for multipath routes · 6ac66cb0
      Sriram Yagnaraman authored
      Route hints when the nexthop is part of a multipath group causes packets
      in the same receive batch to be sent to the same nexthop irrespective of
      the multipath hash of the packet. So, do not extract route hint for
      packets whose destination is part of a multipath group.
      
      A new SKB flag IPSKB_MULTIPATH is introduced for this purpose, set the
      flag when route is looked up in ip_mkroute_input() and use it in
      ip_extract_route_hint() to check for the existence of the flag.
      
      Fixes: 02b24941 ("ipv4: use dst hint for ipv4 list receive")
      Signed-off-by: default avatarSriram Yagnaraman <sriram.yagnaraman@est.tech>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ac66cb0
    • Mohamed Khalfella's avatar
      skbuff: skb_segment, Call zero copy functions before using skbuff frags · 2ea35288
      Mohamed Khalfella authored
      Commit bf5c25d6 ("skbuff: in skb_segment, call zerocopy functions
      once per nskb") added the call to zero copy functions in skb_segment().
      The change introduced a bug in skb_segment() because skb_orphan_frags()
      may possibly change the number of fragments or allocate new fragments
      altogether leaving nrfrags and frag to point to the old values. This can
      cause a panic with stacktrace like the one below.
      
      [  193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc
      [  193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G           O      5.15.123+ #26
      [  193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0
      [  194.021892] Call Trace:
      [  194.027422]  <TASK>
      [  194.072861]  tcp_gso_segment+0x107/0x540
      [  194.082031]  inet_gso_segment+0x15c/0x3d0
      [  194.090783]  skb_mac_gso_segment+0x9f/0x110
      [  194.095016]  __skb_gso_segment+0xc1/0x190
      [  194.103131]  netem_enqueue+0x290/0xb10 [sch_netem]
      [  194.107071]  dev_qdisc_enqueue+0x16/0x70
      [  194.110884]  __dev_queue_xmit+0x63b/0xb30
      [  194.121670]  bond_start_xmit+0x159/0x380 [bonding]
      [  194.128506]  dev_hard_start_xmit+0xc3/0x1e0
      [  194.131787]  __dev_queue_xmit+0x8a0/0xb30
      [  194.138225]  macvlan_start_xmit+0x4f/0x100 [macvlan]
      [  194.141477]  dev_hard_start_xmit+0xc3/0x1e0
      [  194.144622]  sch_direct_xmit+0xe3/0x280
      [  194.147748]  __dev_queue_xmit+0x54a/0xb30
      [  194.154131]  tap_get_user+0x2a8/0x9c0 [tap]
      [  194.157358]  tap_sendmsg+0x52/0x8e0 [tap]
      [  194.167049]  handle_tx_zerocopy+0x14e/0x4c0 [vhost_net]
      [  194.173631]  handle_tx+0xcd/0xe0 [vhost_net]
      [  194.176959]  vhost_worker+0x76/0xb0 [vhost]
      [  194.183667]  kthread+0x118/0x140
      [  194.190358]  ret_from_fork+0x1f/0x30
      [  194.193670]  </TASK>
      
      In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags
      local variable in skb_segment() stale. This resulted in the code hitting
      i >= nrfrags prematurely and trying to move to next frag_skb using
      list_skb pointer, which was NULL, and caused kernel panic. Move the call
      to zero copy functions before using frags and nr_frags.
      
      Fixes: bf5c25d6 ("skbuff: in skb_segment, call zerocopy functions once per nskb")
      Signed-off-by: default avatarMohamed Khalfella <mkhalfella@purestorage.com>
      Reported-by: default avatarAmit Goyal <agoyal@purestorage.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ea35288
    • David S. Miller's avatar
      Merge branch 'net-data-race-annotations' · f2e977f3
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      net: another round of data-race annotations
      
      Series inspired by some syzbot reports, taking care
      of 4 socket fields that can be read locklessly.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2e977f3
    • Eric Dumazet's avatar
      net: annotate data-races around sk->sk_bind_phc · 251cd405
      Eric Dumazet authored
      sk->sk_bind_phc is read locklessly. Add corresponding annotations.
      
      Fixes: d463126e ("net: sock: extend SO_TIMESTAMPING for PHC binding")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Yangbo Lu <yangbo.lu@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      251cd405
    • Eric Dumazet's avatar
      net: annotate data-races around sk->sk_tsflags · e3390b30
      Eric Dumazet authored
      sk->sk_tsflags can be read locklessly, add corresponding annotations.
      
      Fixes: b9f40e21 ("net-timestamp: move timestamp flags out of sk_flags")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3390b30
    • Eric Dumazet's avatar
      mptcp: annotate data-races around msk->rmem_fwd_alloc · 9531e4a8
      Eric Dumazet authored
      msk->rmem_fwd_alloc can be read locklessly.
      
      Add mptcp_rmem_fwd_alloc_add(), similar to sk_forward_alloc_add(),
      and appropriate READ_ONCE()/WRITE_ONCE() annotations.
      
      Fixes: 6511882c ("mptcp: allocate fwd memory separately on the rx and tx path")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9531e4a8
    • Eric Dumazet's avatar
      net: annotate data-races around sk->sk_forward_alloc · 5e6300e7
      Eric Dumazet authored
      Every time sk->sk_forward_alloc is read locklessly,
      add a READ_ONCE().
      
      Add sk_forward_alloc_add() helper to centralize updates,
      to reduce number of WRITE_ONCE().
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e6300e7
    • Eric Dumazet's avatar
      net: use sk_forward_alloc_get() in sk_get_meminfo() · 66d58f04
      Eric Dumazet authored
      inet_sk_diag_fill() has been changed to use sk_forward_alloc_get(),
      but sk_get_meminfo() was forgotten.
      
      Fixes: 292e6077 ("net: introduce sk_forward_alloc_get()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66d58f04
    • Eric Dumazet's avatar
      net/handshake: fix null-ptr-deref in handshake_nl_done_doit() · 82ba0ff7
      Eric Dumazet authored
      We should not call trace_handshake_cmd_done_err() if socket lookup has failed.
      
      Also we should call trace_handshake_cmd_done_err() before releasing the file,
      otherwise dereferencing sock->sk can return garbage.
      
      This also reverts 7afc6d0a ("net/handshake: Fix uninitialized local variable")
      
      Unable to handle kernel paging request at virtual address dfff800000000003
      KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
      Mem abort info:
      ESR = 0x0000000096000005
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x05: level 1 translation fault
      Data abort info:
      ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
      [dfff800000000003] address between user and kernel address ranges
      Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
      pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
      lr : handshake_nl_done_doit+0x180/0x9c8
      sp : ffff800096e37180
      x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000
      x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8
      x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000
      x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000
      x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001
      x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003
      x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000
      x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078
      x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000
      Call trace:
      handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
      genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]
      genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]
      genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067
      netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549
      genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078
      netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
      netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
      netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914
      sock_sendmsg_nosec net/socket.c:725 [inline]
      sock_sendmsg net/socket.c:748 [inline]
      ____sys_sendmsg+0x56c/0x840 net/socket.c:2494
      ___sys_sendmsg net/socket.c:2548 [inline]
      __sys_sendmsg+0x26c/0x33c net/socket.c:2577
      __do_sys_sendmsg net/socket.c:2586 [inline]
      __se_sys_sendmsg net/socket.c:2584 [inline]
      __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584
      __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
      invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
      el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
      do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
      el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
      el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
      el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
      Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908)
      
      Fixes: 3b3009ea ("net/handshake: Create a NETLINK service for handling handshake requests")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarMichal Kubiak <michal.kubiak@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82ba0ff7
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · ddaa935d
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2023-08-31
      
      We've added 15 non-merge commits during the last 3 day(s) which contain
      a total of 17 files changed, 468 insertions(+), 97 deletions(-).
      
      The main changes are:
      
      1) BPF selftest fixes: one flake and one related to clang18 testing,
         from Yonghong Song.
      
      2) Fix a d_path BPF selftest failure after fast-forward from Linus'
         tree, from Jiri Olsa.
      
      3) Fix a preempt_rt splat in sockmap when using raw_spin_lock_t,
         from John Fastabend.
      
      4) Fix a xsk_diag_fill use-after-free race during socket cleanup,
         from Magnus Karlsson.
      
      5) Fix xsk_build_skb to address a buggy dereference of an ERR_PTR(),
         from Tirthendu Sarkar.
      
      6) Fix a bpftool build warning when compiled with -Wtype-limits,
         from Yafang Shao.
      
      7) Several misc fixes and cleanups in standardization docs,
         from David Vernet.
      
      8) Fix BPF selftest install to consider no_alu32/cpuv4/bpf-gcc flavors,
         from Björn Töpel.
      
      9) Annotate a data race in bpf_long_memcpy for KCSAN, from Daniel Borkmann.
      
      10) Extend documentation with a description for CO-RE relocations,
          from Eduard Zingerman.
      
      11) Fix several invalid escape sequence warnings in bpf_doc.py script,
          from Vishal Chourasia.
      
      12) Fix the instruction set doc wrt offset of BPF-to-BPF call,
          from Will Hawkins.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        selftests/bpf: Include build flavors for install target
        bpf: Annotate bpf_long_memcpy with data_race
        selftests/bpf: Fix d_path test
        bpf, docs: Fix invalid escape sequence warnings in bpf_doc.py
        xsk: Fix xsk_diag use-after-free error during socket cleanup
        bpf, docs: s/eBPF/BPF in standards documents
        bpf, docs: Add abi.rst document to standardization subdirectory
        bpf, docs: Move linux-notes.rst to root bpf docs tree
        bpf, sockmap: Fix preempt_rt splat when using raw_spin_lock_t
        docs/bpf: Add description for CO-RE relocations
        bpf, docs: Correct source of offset for program-local call
        selftests/bpf: Fix flaky cgroup_iter_sleepable subtest
        xsk: Fix xsk_build_skb() error: 'skb' dereferencing possible ERR_PTR()
        bpftool: Fix build warnings with -Wtype-limits
        bpf: Prevent inlining of bpf_fentry_test7()
      ====================
      
      Link: https://lore.kernel.org/r/20230831210019.14417-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ddaa935d
  10. 31 Aug, 2023 2 commits
    • Björn Töpel's avatar
      selftests/bpf: Include build flavors for install target · be8e754c
      Björn Töpel authored
      When using the "install" or targets depending on install, e.g. "gen_tar",
      the BPF machine flavors weren't included.
      
      A command like:
        | make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- O=/workspace/kbuild \
        |    HOSTCC=gcc FORMAT= SKIP_TARGETS="arm64 ia64 powerpc sparc64 x86 sgx" \
        |    -C tools/testing/selftests gen_tar
      would not include bpf/no_alu32, bpf/cpuv4, or bpf/bpf-gcc.
      
      Include the BPF machine flavors for "install" make target.
      Signed-off-by: default avatarBjörn Töpel <bjorn@rivosinc.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20230831162954.111485-1-bjorn@kernel.org
      be8e754c
    • Daniel Borkmann's avatar
      bpf: Annotate bpf_long_memcpy with data_race · 6a86b5b5
      Daniel Borkmann authored
      syzbot reported a data race splat between two processes trying to
      update the same BPF map value via syscall on different CPUs:
      
        BUG: KCSAN: data-race in bpf_percpu_array_update / bpf_percpu_array_update
      
        write to 0xffffe8fffe7425d8 of 8 bytes by task 8257 on cpu 1:
         bpf_long_memcpy include/linux/bpf.h:428 [inline]
         bpf_obj_memcpy include/linux/bpf.h:441 [inline]
         copy_map_value_long include/linux/bpf.h:464 [inline]
         bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380
         bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175
         generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749
         bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648
         __sys_bpf+0x28a/0x780
         __do_sys_bpf kernel/bpf/syscall.c:5241 [inline]
         __se_sys_bpf kernel/bpf/syscall.c:5239 [inline]
         __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239
         do_syscall_x64 arch/x86/entry/common.c:50 [inline]
         do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
         entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
        write to 0xffffe8fffe7425d8 of 8 bytes by task 8268 on cpu 0:
         bpf_long_memcpy include/linux/bpf.h:428 [inline]
         bpf_obj_memcpy include/linux/bpf.h:441 [inline]
         copy_map_value_long include/linux/bpf.h:464 [inline]
         bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380
         bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175
         generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749
         bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648
         __sys_bpf+0x28a/0x780
         __do_sys_bpf kernel/bpf/syscall.c:5241 [inline]
         __se_sys_bpf kernel/bpf/syscall.c:5239 [inline]
         __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239
         do_syscall_x64 arch/x86/entry/common.c:50 [inline]
         do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
         entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
        value changed: 0x0000000000000000 -> 0xfffffff000002788
      
      The bpf_long_memcpy is used with 8-byte aligned pointers, power-of-8 size
      and forced to use long read/writes to try to atomically copy long counters.
      It is best-effort only and no barriers are here since it _will_ race with
      concurrent updates from BPF programs. The bpf_long_memcpy() is called from
      bpf(2) syscall. Marco suggested that the best way to make this known to
      KCSAN would be to use data_race() annotation.
      
      Reported-by: syzbot+97522333291430dd277f@syzkaller.appspotmail.com
      Suggested-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarMarco Elver <elver@google.com>
      Link: https://lore.kernel.org/bpf/000000000000d87a7f06040c970c@google.com
      Link: https://lore.kernel.org/bpf/57628f7a15e20d502247c3b55fceb1cb2b31f266.1693342186.git.daniel@iogearbox.net
      6a86b5b5