1. 04 4月, 2023 1 次提交
  2. 07 2月, 2023 1 次提交
    • E
      net: sched: fix race condition in qdisc_graft() · 55760a4c
      Eric Dumazet 提交于
      stable inclusion
      from stable-v5.10.152
      commit 7aa3d623c11b9ab60f86b7833666e5d55bac4be9
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I64L17
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7aa3d623c11b9ab60f86b7833666e5d55bac4be9
      
      --------------------------------
      
      [ Upstream commit ebda44da ]
      
      We had one syzbot report [1] in syzbot queue for a while.
      I was waiting for more occurrences and/or a repro but
      Dmitry Vyukov spotted the issue right away.
      
      <quoting Dmitry>
      qdisc_graft() drops reference to qdisc in notify_and_destroy
      while it's still assigned to dev->qdisc
      </quoting>
      
      Indeed, RCU rules are clear when replacing a data structure.
      The visible pointer (dev->qdisc in this case) must be updated
      to the new object _before_ RCU grace period is started
      (qdisc_put(old) in this case).
      
      [1]
      BUG: KASAN: use-after-free in __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066
      Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027
      
      CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
      print_address_description mm/kasan/report.c:317 [inline]
      print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
      kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
      __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066
      __tcf_qdisc_find net/sched/cls_api.c:1051 [inline]
      tc_new_tfilter+0x34f/0x2200 net/sched/cls_api.c:2018
      rtnetlink_rcv_msg+0x955/0xca0 net/core/rtnetlink.c:6081
      netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
      netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
      netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
      netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xcf/0x120 net/socket.c:734
      ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
      ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
      __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7f5efaa89279
      Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f5efbc31168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f5efab9bf80 RCX: 00007f5efaa89279
      RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
      RBP: 00007f5efaae32e9 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007f5efb0cfb1f R14: 00007f5efbc31300 R15: 0000000000022000
      </TASK>
      
      Allocated by task 21027:
      kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
      kasan_set_track mm/kasan/common.c:45 [inline]
      set_alloc_info mm/kasan/common.c:437 [inline]
      ____kasan_kmalloc mm/kasan/common.c:516 [inline]
      ____kasan_kmalloc mm/kasan/common.c:475 [inline]
      __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525
      kmalloc_node include/linux/slab.h:623 [inline]
      kzalloc_node include/linux/slab.h:744 [inline]
      qdisc_alloc+0xb0/0xc50 net/sched/sch_generic.c:938
      qdisc_create_dflt+0x71/0x4a0 net/sched/sch_generic.c:997
      attach_one_default_qdisc net/sched/sch_generic.c:1152 [inline]
      netdev_for_each_tx_queue include/linux/netdevice.h:2437 [inline]
      attach_default_qdiscs net/sched/sch_generic.c:1170 [inline]
      dev_activate+0x760/0xcd0 net/sched/sch_generic.c:1229
      __dev_open+0x393/0x4d0 net/core/dev.c:1441
      __dev_change_flags+0x583/0x750 net/core/dev.c:8556
      rtnl_configure_link+0xee/0x240 net/core/rtnetlink.c:3189
      rtnl_newlink_create net/core/rtnetlink.c:3371 [inline]
      __rtnl_newlink+0x10b8/0x17e0 net/core/rtnetlink.c:3580
      rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
      rtnetlink_rcv_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
      netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
      netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
      netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
      netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xcf/0x120 net/socket.c:734
      ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
      ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
      __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Freed by task 21020:
      kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
      kasan_set_track+0x21/0x30 mm/kasan/common.c:45
      kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
      ____kasan_slab_free mm/kasan/common.c:367 [inline]
      ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329
      kasan_slab_free include/linux/kasan.h:200 [inline]
      slab_free_hook mm/slub.c:1754 [inline]
      slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1780
      slab_free mm/slub.c:3534 [inline]
      kfree+0xe2/0x580 mm/slub.c:4562
      rcu_do_batch kernel/rcu/tree.c:2245 [inline]
      rcu_core+0x7b5/0x1890 kernel/rcu/tree.c:2505
      __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
      
      Last potentially related work creation:
      kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
      __kasan_record_aux_stack+0xbe/0xd0 mm/kasan/generic.c:348
      call_rcu+0x99/0x790 kernel/rcu/tree.c:2793
      qdisc_put+0xcd/0xe0 net/sched/sch_generic.c:1083
      notify_and_destroy net/sched/sch_api.c:1012 [inline]
      qdisc_graft+0xeb1/0x1270 net/sched/sch_api.c:1084
      tc_modify_qdisc+0xbb7/0x1a00 net/sched/sch_api.c:1671
      rtnetlink_rcv_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
      netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
      netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
      netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
      netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xcf/0x120 net/socket.c:734
      ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
      ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
      __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Second to last potentially related work creation:
      kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
      __kasan_record_aux_stack+0xbe/0xd0 mm/kasan/generic.c:348
      kvfree_call_rcu+0x74/0x940 kernel/rcu/tree.c:3322
      neigh_destroy+0x431/0x630 net/core/neighbour.c:912
      neigh_release include/net/neighbour.h:454 [inline]
      neigh_cleanup_and_release+0x1f8/0x330 net/core/neighbour.c:103
      neigh_del net/core/neighbour.c:225 [inline]
      neigh_remove_one+0x37d/0x460 net/core/neighbour.c:246
      neigh_forced_gc net/core/neighbour.c:276 [inline]
      neigh_alloc net/core/neighbour.c:447 [inline]
      ___neigh_create+0x18b5/0x29a0 net/core/neighbour.c:642
      ip6_finish_output2+0xfb8/0x1520 net/ipv6/ip6_output.c:125
      __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
      ip6_finish_output+0x690/0x1160 net/ipv6/ip6_output.c:206
      NF_HOOK_COND include/linux/netfilter.h:296 [inline]
      ip6_output+0x1ed/0x540 net/ipv6/ip6_output.c:227
      dst_output include/net/dst.h:451 [inline]
      NF_HOOK include/linux/netfilter.h:307 [inline]
      NF_HOOK include/linux/netfilter.h:301 [inline]
      mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820
      mld_send_cr net/ipv6/mcast.c:2121 [inline]
      mld_ifc_work+0x71c/0xdc0 net/ipv6/mcast.c:2653
      process_one_work+0x991/0x1610 kernel/workqueue.c:2289
      worker_thread+0x665/0x1080 kernel/workqueue.c:2436
      kthread+0x2e4/0x3a0 kernel/kthread.c:376
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
      
      The buggy address belongs to the object at ffff88802065e000
      which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 56 bytes inside of
      1024-byte region [ffff88802065e000, ffff88802065e400)
      
      The buggy address belongs to the physical page:
      page:ffffea0000819600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20658
      head:ffffea0000819600 order:3 compound_mapcount:0 compound_pincount:0
      flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000010200 0000000000000000 dead000000000001 ffff888011841dc0
      raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as allocated
      page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 3523, tgid 3523 (sshd), ts 41495190986, free_ts 41417713212
      prep_new_page mm/page_alloc.c:2532 [inline]
      get_page_from_freelist+0x109b/0x2ce0 mm/page_alloc.c:4283
      __alloc_pages+0x1c7/0x510 mm/page_alloc.c:5515
      alloc_pages+0x1a6/0x270 mm/mempolicy.c:2270
      alloc_slab_page mm/slub.c:1824 [inline]
      allocate_slab+0x27e/0x3d0 mm/slub.c:1969
      new_slab mm/slub.c:2029 [inline]
      ___slab_alloc+0x7f1/0xe10 mm/slub.c:3031
      __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3118
      slab_alloc_node mm/slub.c:3209 [inline]
      __kmalloc_node_track_caller+0x2f2/0x380 mm/slub.c:4955
      kmalloc_reserve net/core/skbuff.c:358 [inline]
      __alloc_skb+0xd9/0x2f0 net/core/skbuff.c:430
      alloc_skb_fclone include/linux/skbuff.h:1307 [inline]
      tcp_stream_alloc_skb+0x38/0x580 net/ipv4/tcp.c:861
      tcp_sendmsg_locked+0xc36/0x2f80 net/ipv4/tcp.c:1325
      tcp_sendmsg+0x2b/0x40 net/ipv4/tcp.c:1483
      inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xcf/0x120 net/socket.c:734
      sock_write_iter+0x291/0x3d0 net/socket.c:1108
      call_write_iter include/linux/fs.h:2187 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x9e9/0xdd0 fs/read_write.c:578
      ksys_write+0x1e8/0x250 fs/read_write.c:631
      page last free stack trace:
      reset_page_owner include/linux/page_owner.h:24 [inline]
      free_pages_prepare mm/page_alloc.c:1449 [inline]
      free_pcp_prepare+0x5e4/0xd20 mm/page_alloc.c:1499
      free_unref_page_prepare mm/page_alloc.c:3380 [inline]
      free_unref_page+0x19/0x4d0 mm/page_alloc.c:3476
      __unfreeze_partials+0x17c/0x1a0 mm/slub.c:2548
      qlink_free mm/kasan/quarantine.c:168 [inline]
      qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187
      kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:294
      __kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:447
      kasan_slab_alloc include/linux/kasan.h:224 [inline]
      slab_post_alloc_hook mm/slab.h:727 [inline]
      slab_alloc_node mm/slub.c:3243 [inline]
      slab_alloc mm/slub.c:3251 [inline]
      __kmem_cache_alloc_lru mm/slub.c:3258 [inline]
      kmem_cache_alloc+0x267/0x3b0 mm/slub.c:3268
      kmem_cache_zalloc include/linux/slab.h:723 [inline]
      alloc_buffer_head+0x20/0x140 fs/buffer.c:2974
      alloc_page_buffers+0x280/0x790 fs/buffer.c:829
      create_empty_buffers+0x2c/0xee0 fs/buffer.c:1558
      ext4_block_write_begin+0x1004/0x1530 fs/ext4/inode.c:1074
      ext4_da_write_begin+0x422/0xae0 fs/ext4/inode.c:2996
      generic_perform_write+0x246/0x560 mm/filemap.c:3738
      ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:270
      ext4_file_write_iter+0x44a/0x1660 fs/ext4/file.c:679
      call_write_iter include/linux/fs.h:2187 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x9e9/0xdd0 fs/read_write.c:578
      
      Fixes: af356afa ("net_sched: reintroduce dev->qdisc for use by sch_api")
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Diagnosed-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20221018203258.2793282-1-edumazet@google.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
      Reviewed-by: NLiu Jian <liujian56@huawei.com>
      Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      55760a4c
  3. 31 1月, 2023 1 次提交
    • F
      net: sched: disallow noqueue for qdisc classes · 6b55e28d
      Frederick Lawler 提交于
      stable inclusion
      from stable-v5.10.163
      commit 9f7bc28a6b8afc2274e25650511555e93f45470f
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6B0FA
      CVE: CVE-2022-47929
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9f7bc28a6b8afc2274e25650511555e93f45470f
      
      --------------------------------
      
      commit 96398560 upstream.
      
      While experimenting with applying noqueue to a classful queue discipline,
      we discovered a NULL pointer dereference in the __dev_queue_xmit()
      path that generates a kernel OOPS:
      
          # dev=enp0s5
          # tc qdisc replace dev $dev root handle 1: htb default 1
          # tc class add dev $dev parent 1: classid 1:1 htb rate 10mbit
          # tc qdisc add dev $dev parent 1:1 handle 10: noqueue
          # ping -I $dev -w 1 -c 1 1.1.1.1
      
      [    2.172856] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [    2.173217] #PF: supervisor instruction fetch in kernel mode
      ...
      [    2.178451] Call Trace:
      [    2.178577]  <TASK>
      [    2.178686]  htb_enqueue+0x1c8/0x370
      [    2.178880]  dev_qdisc_enqueue+0x15/0x90
      [    2.179093]  __dev_queue_xmit+0x798/0xd00
      [    2.179305]  ? _raw_write_lock_bh+0xe/0x30
      [    2.179522]  ? __local_bh_enable_ip+0x32/0x70
      [    2.179759]  ? ___neigh_create+0x610/0x840
      [    2.179968]  ? eth_header+0x21/0xc0
      [    2.180144]  ip_finish_output2+0x15e/0x4f0
      [    2.180348]  ? dst_output+0x30/0x30
      [    2.180525]  ip_push_pending_frames+0x9d/0xb0
      [    2.180739]  raw_sendmsg+0x601/0xcb0
      [    2.180916]  ? _raw_spin_trylock+0xe/0x50
      [    2.181112]  ? _raw_spin_unlock_irqrestore+0x16/0x30
      [    2.181354]  ? get_page_from_freelist+0xcd6/0xdf0
      [    2.181594]  ? sock_sendmsg+0x56/0x60
      [    2.181781]  sock_sendmsg+0x56/0x60
      [    2.181958]  __sys_sendto+0xf7/0x160
      [    2.182139]  ? handle_mm_fault+0x6e/0x1d0
      [    2.182366]  ? do_user_addr_fault+0x1e1/0x660
      [    2.182627]  __x64_sys_sendto+0x1b/0x30
      [    2.182881]  do_syscall_64+0x38/0x90
      [    2.183085]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
      ...
      [    2.187402]  </TASK>
      
      Previously in commit d66d6c31 ("net: sched: register noqueue
      qdisc"), NULL was set for the noqueue discipline on noqueue init
      so that __dev_queue_xmit() falls through for the noqueue case. This
      also sets a bypass of the enqueue NULL check in the
      register_qdisc() function for the struct noqueue_disc_ops.
      
      Classful queue disciplines make it past the NULL check in
      __dev_queue_xmit() because the discipline is set to htb (in this case),
      and then in the call to __dev_xmit_skb(), it calls into htb_enqueue()
      which grabs a leaf node for a class and then calls qdisc_enqueue() by
      passing in a queue discipline which assumes ->enqueue() is not set to NULL.
      
      Fix this by not allowing classes to be assigned to the noqueue
      discipline. Linux TC Notes states that classes cannot be set to
      the noqueue discipline. [1] Let's enforce that here.
      
      Links:
      1. https://linux-tc-notes.sourceforge.net/tc/doc/sch_noqueue.txt
      
      Fixes: d66d6c31 ("net: sched: register noqueue qdisc")
      Cc: stable@vger.kernel.org
      Signed-off-by: NFrederick Lawler <fred@cloudflare.com>
      Reviewed-by: NJakub Sitnicki <jakub@cloudflare.com>
      Link: https://lore.kernel.org/r/20230109163906.706000-1-fred@cloudflare.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
      Reviewed-by: NLiu Jian <liujian56@huawei.com>
      Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      6b55e28d
  4. 23 5月, 2022 1 次提交
    • E
      net_sched: add __rcu annotation to netdev->qdisc · 30a4105a
      Eric Dumazet 提交于
      stable inclusion
      from stable-v5.10.102
      commit d9bd9d4c60c34fe3e71732b8edcba3a880193948
      bugzilla: https://gitee.com/openeuler/kernel/issues/I567K6
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d9bd9d4c60c34fe3e71732b8edcba3a880193948
      
      --------------------------------
      
      commit 5891cd5e upstream.
      
      syzbot found a data-race [1] which lead me to add __rcu
      annotations to netdev->qdisc, and proper accessors
      to get LOCKDEP support.
      
      [1]
      BUG: KCSAN: data-race in dev_activate / qdisc_lookup_rcu
      
      write to 0xffff888168ad6410 of 8 bytes by task 13559 on cpu 1:
       attach_default_qdiscs net/sched/sch_generic.c:1167 [inline]
       dev_activate+0x2ed/0x8f0 net/sched/sch_generic.c:1221
       __dev_open+0x2e9/0x3a0 net/core/dev.c:1416
       __dev_change_flags+0x167/0x3f0 net/core/dev.c:8139
       rtnl_configure_link+0xc2/0x150 net/core/rtnetlink.c:3150
       __rtnl_newlink net/core/rtnetlink.c:3489 [inline]
       rtnl_newlink+0xf4d/0x13e0 net/core/rtnetlink.c:3529
       rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5594
       netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494
       rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5612
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919
       sock_sendmsg_nosec net/socket.c:705 [inline]
       sock_sendmsg net/socket.c:725 [inline]
       ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
       ___sys_sendmsg net/socket.c:2467 [inline]
       __sys_sendmsg+0x195/0x230 net/socket.c:2496
       __do_sys_sendmsg net/socket.c:2505 [inline]
       __se_sys_sendmsg net/socket.c:2503 [inline]
       __x64_sys_sendmsg+0x42/0x50 net/socket.c:2503
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      read to 0xffff888168ad6410 of 8 bytes by task 13560 on cpu 0:
       qdisc_lookup_rcu+0x30/0x2e0 net/sched/sch_api.c:323
       __tcf_qdisc_find+0x74/0x3a0 net/sched/cls_api.c:1050
       tc_del_tfilter+0x1c7/0x1350 net/sched/cls_api.c:2211
       rtnetlink_rcv_msg+0x5ba/0x7e0 net/core/rtnetlink.c:5585
       netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494
       rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5612
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919
       sock_sendmsg_nosec net/socket.c:705 [inline]
       sock_sendmsg net/socket.c:725 [inline]
       ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
       ___sys_sendmsg net/socket.c:2467 [inline]
       __sys_sendmsg+0x195/0x230 net/socket.c:2496
       __do_sys_sendmsg net/socket.c:2505 [inline]
       __se_sys_sendmsg net/socket.c:2503 [inline]
       __x64_sys_sendmsg+0x42/0x50 net/socket.c:2503
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      value changed: 0xffffffff85dee080 -> 0xffff88815d96ec00
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 13560 Comm: syz-executor.2 Not tainted 5.17.0-rc3-syzkaller-00116-gf1baf68e-dirty #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: 470502de ("net: sched: unlock rules update API")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Vlad Buslov <vladbu@mellanox.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYu Liao <liaoyu15@huawei.com>
      Reviewed-by: NWei Li <liwei391@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      30a4105a
  5. 19 5月, 2022 1 次提交
  6. 15 11月, 2021 1 次提交
  7. 09 4月, 2021 1 次提交
  8. 08 2月, 2021 1 次提交
    • E
      net_sched: reject silly cell_log in qdisc_get_rtab() · 9e5e91bb
      Eric Dumazet 提交于
      stable inclusion
      from stable-5.10.11
      commit 0083dc292ee4f6357cdbcd530fb46eafb391bc32
      bugzilla: 47621
      
      --------------------------------
      
      commit e4bedf48 upstream.
      
      iproute2 probably never goes beyond 8 for the cell exponent,
      but stick to the max shift exponent for signed 32bit.
      
      UBSAN reported:
      UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
      shift exponent 130 is too large for 32-bit type 'int'
      CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:79 [inline]
       dump_stack+0x183/0x22e lib/dump_stack.c:120
       ubsan_epilogue lib/ubsan.c:148 [inline]
       __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395
       __detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389
       qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435
       cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180
       qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246
       tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662
       rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564
       netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494
       netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
       netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330
       netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg net/socket.c:672 [inline]
       ____sys_sendmsg+0x5a2/0x900 net/socket.c:2345
       ___sys_sendmsg net/socket.c:2399 [inline]
       __sys_sendmsg+0x319/0x400 net/socket.c:2432
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NCong Wang <cong.wang@bytedance.com>
      Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
      9e5e91bb
  9. 21 7月, 2020 1 次提交
    • J
      sched: sch_api: add missing rcu read lock to silence the warning · a8b7b2d0
      Jiri Pirko 提交于
      In case the qdisc_match_from_root function() is called from non-rcu path
      with rtnl mutex held, a suspiciout rcu usage warning appears:
      
      [  241.504354] =============================
      [  241.504358] WARNING: suspicious RCU usage
      [  241.504366] 5.8.0-rc4-custom-01521-g72a7c7d549c3 #32 Not tainted
      [  241.504370] -----------------------------
      [  241.504378] net/sched/sch_api.c:270 RCU-list traversed in non-reader section!!
      [  241.504382]
                     other info that might help us debug this:
      [  241.504388]
                     rcu_scheduler_active = 2, debug_locks = 1
      [  241.504394] 1 lock held by tc/1391:
      [  241.504398]  #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
      [  241.504431]
                     stack backtrace:
      [  241.504440] CPU: 0 PID: 1391 Comm: tc Not tainted 5.8.0-rc4-custom-01521-g72a7c7d549c3 #32
      [  241.504446] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      [  241.504453] Call Trace:
      [  241.504465]  dump_stack+0x100/0x184
      [  241.504482]  lockdep_rcu_suspicious+0x153/0x15d
      [  241.504499]  qdisc_match_from_root+0x293/0x350
      
      Fix this by passing the rtnl held lockdep condition down to
      hlist_for_each_entry_rcu()
      Reported-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8b7b2d0
  10. 21 6月, 2020 1 次提交
  11. 28 5月, 2020 1 次提交
    • C
      net_sched: add a tracepoint for qdisc creation · f5a7833e
      Cong Wang 提交于
      With this tracepoint, we could know when qdisc's are created,
      especially those default qdisc's.
      
      Sample output:
      
        tc-736   [001] ...1    56.230107: qdisc_create: dev=ens3 kind=pfifo parent=1:0
        tc-736   [001] ...1    56.230113: qdisc_create: dev=ens3 kind=hfsc parent=ffff:ffff
        tc-738   [001] ...1    56.256816: qdisc_create: dev=ens3 kind=pfifo parent=1:100
        tc-739   [001] ...1    56.267584: qdisc_create: dev=ens3 kind=pfifo parent=1:200
        tc-740   [001] ...1    56.279649: qdisc_create: dev=ens3 kind=fq_codel parent=1:100
        tc-741   [001] ...1    56.289996: qdisc_create: dev=ens3 kind=pfifo_fast parent=1:200
        tc-745   [000] .N.1   111.687483: qdisc_create: dev=ens3 kind=ingress parent=ffff:fff1
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5a7833e
  12. 18 3月, 2020 2 次提交
  13. 27 1月, 2020 2 次提交
    • C
      net_sched: walk through all child classes in tc_bind_tclass() · 760d228e
      Cong Wang 提交于
      In a complex TC class hierarchy like this:
      
      tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit         \
        avpkt 1000 cell 8
      tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  \
        rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20      \
        avpkt 1000 bounded
      
      tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
        sport 80 0xffff flowid 1:3
      tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
        sport 25 0xffff flowid 1:4
      
      tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit  \
        rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20      \
        avpkt 1000
      tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit  \
        rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20      \
        avpkt 1000
      
      where filters are installed on qdisc 1:0, so we can't merely
      search from class 1:1 when creating class 1:3 and class 1:4. We have
      to walk through all the child classes of the direct parent qdisc.
      Otherwise we would miss filters those need reverse binding.
      
      Fixes: 07d79fc7 ("net_sched: add reverse binding for tc class")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      760d228e
    • C
      net_sched: fix ops->bind_class() implementations · 2e24cd75
      Cong Wang 提交于
      The current implementations of ops->bind_class() are merely
      searching for classid and updating class in the struct tcf_result,
      without invoking either of cl_ops->bind_tcf() or
      cl_ops->unbind_tcf(). This breaks the design of them as qdisc's
      like cbq use them to count filters too. This is why syzbot triggered
      the warning in cbq_destroy_class().
      
      In order to fix this, we have to call cl_ops->bind_tcf() and
      cl_ops->unbind_tcf() like the filter binding path. This patch does
      so by refactoring out two helper functions __tcf_bind_filter()
      and __tcf_unbind_filter(), which are lockless and accept a Qdisc
      pointer, then teaching each implementation to call them correctly.
      
      Note, we merely pass the Qdisc pointer as an opaque pointer to
      each filter, they only need to pass it down to the helper
      functions without understanding it at all.
      
      Fixes: 07d79fc7 ("net_sched: add reverse binding for tc class")
      Reported-and-tested-by: syzbot+0a0596220218fcb603a8@syzkaller.appspotmail.com
      Reported-and-tested-by: syzbot+63bdb6006961d8c917c6@syzkaller.appspotmail.com
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e24cd75
  14. 09 10月, 2019 1 次提交
  15. 22 9月, 2019 1 次提交
  16. 11 9月, 2019 1 次提交
  17. 31 5月, 2019 1 次提交
  18. 28 4月, 2019 2 次提交
    • J
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg 提交于
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb08174
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  19. 11 4月, 2019 1 次提交
    • P
      net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too · 8a53e616
      Paolo Abeni 提交于
      Since stats updating is always consistent with TCQ_F_CPUSTATS flag,
      we can disable it at qdisc creation time flipping such bit.
      
      In my experiments, if the NOLOCK flag is cleared, per CPU stats
      accounting does not give any measurable performance gain, but it
      waste some memory.
      
      Let's clear TCQ_F_CPUSTATS together with NOLOCK, when enslaving
      a NOLOCK qdisc to 'lock' one.
      
      Use stats update helper inside pfifo_fast, to cope correctly with
      TCQ_F_CPUSTATS flag change.
      
      As a side effect, q.qlen value for any child qdiscs is always
      consistent for all lock classfull qdiscs.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a53e616
  20. 14 3月, 2019 1 次提交
  21. 19 2月, 2019 1 次提交
  22. 18 2月, 2019 1 次提交
  23. 13 2月, 2019 3 次提交
  24. 20 1月, 2019 1 次提交
  25. 16 12月, 2018 1 次提交
  26. 02 12月, 2018 1 次提交
    • P
      net/sched: Replace call_rcu_bh() and rcu_barrier_bh() · ae0e3349
      Paul E. McKenney 提交于
      Now that call_rcu()'s callback is not invoked until after bh-disable
      regions of code have completed (in addition to explicitly marked
      RCU read-side critical sections), call_rcu() can be used in place
      of call_rcu_bh().  Similarly, rcu_barrier() can be used in place o
      frcu_barrier_bh().  This commit therefore makes these changes.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.ibm.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: <netdev@vger.kernel.org>
      ae0e3349
  27. 15 11月, 2018 1 次提交
  28. 09 11月, 2018 3 次提交
  29. 25 10月, 2018 1 次提交
  30. 19 10月, 2018 1 次提交
    • P
      net: sched: Fix for duplicate class dump · 3c53ed8f
      Phil Sutter 提交于
      When dumping classes by parent, kernel would return classes twice:
      
      | # tc qdisc add dev lo root prio
      | # tc class show dev lo
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      | # tc class show dev lo parent 8001:
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      | class prio 8001:1 parent 8001:
      | class prio 8001:2 parent 8001:
      | class prio 8001:3 parent 8001:
      
      This comes from qdisc_match_from_root() potentially returning the root
      qdisc itself if its handle matched. Though in that case, root's classes
      were already dumped a few lines above.
      
      Fixes: cb395b20 ("net: sched: optimize class dumps")
      Signed-off-by: NPhil Sutter <phil@nwl.cc>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c53ed8f
  31. 16 10月, 2018 1 次提交
    • D
      net/sched: cls_api: add missing validation of netlink attributes · e331473f
      Davide Caratti 提交于
      Similarly to what has been done in 8b4c3cdd ("net: sched: Add policy
      validation for tc attributes"), fix classifier code to add validation of
      TCA_CHAIN and TCA_KIND netlink attributes.
      
      tested with:
       # ./tdc.py -c filter
      
      v2: Let sch_api and cls_api share nla_policy they have in common, thanks
          to David Ahern.
      v3: Avoid EXPORT_SYMBOL(), as validation of those attributes is not done
          by TC modules, thanks to Cong Wang.
          While at it, restore the 'Delete / get qdisc' comment to its orginal
          position, just above tc_get_qdisc() function prototype.
      
      Fixes: 5bc17018 ("net: sched: introduce multichain support for filters")
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e331473f
  32. 09 10月, 2018 1 次提交
  33. 06 10月, 2018 1 次提交
    • D
      net: sched: Add policy validation for tc attributes · 8b4c3cdd
      David Ahern 提交于
      A number of TC attributes are processed without proper validation
      (e.g., length checks). Add a tca policy for all input attributes and use
      when invoking nlmsg_parse.
      
      The 2 Fixes tags below cover the latest additions. The other attributes
      are a string (KIND), nested attribute (OPTIONS which does seem to have
      validation in most cases), for dumps only or a flag.
      
      Fixes: 5bc17018 ("net: sched: introduce multichain support for filters")
      Fixes: d47a6b0e ("net: sched: introduce ingress/egress block index attributes for qdisc")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b4c3cdd