Skip to content
Snippets Groups Projects
  1. Aug 09, 2022
  2. Aug 08, 2022
  3. Aug 05, 2022
    • Ziyang Xuan's avatar
      ipv6/addrconf: fix a null-ptr-deref bug for ip6_ptr · 65db88fb
      Ziyang Xuan authored
      mainline inclusion
      from mainline-v5.19
      commit 85f0173df35e5462d89947135a6a5599c6c3ef6f
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5JW9C
      
      
      CVE: NA
      
      -------------------------------
      
      Change net device's MTU to smaller than IPV6_MIN_MTU or unregister
      device while matching route. That may trigger null-ptr-deref bug
      for ip6_ptr probability as following.
      
      =========================================================
      BUG: KASAN: null-ptr-deref in find_match.part.0+0x70/0x134
      Read of size 4 at addr 0000000000000308 by task ping6/263
      
      CPU: 2 PID: 263 Comm: ping6 Not tainted 5.19.0-rc7+ #14
      Call trace:
       dump_backtrace+0x1a8/0x230
       show_stack+0x20/0x70
       dump_stack_lvl+0x68/0x84
       print_report+0xc4/0x120
       kasan_report+0x84/0x120
       __asan_load4+0x94/0xd0
       find_match.part.0+0x70/0x134
       __find_rr_leaf+0x408/0x470
       fib6_table_lookup+0x264/0x540
       ip6_pol_route+0xf4/0x260
       ip6_pol_route_output+0x58/0x70
       fib6_rule_lookup+0x1a8/0x330
       ip6_route_output_flags_noref+0xd8/0x1a0
       ip6_route_output_flags+0x58/0x160
       ip6_dst_lookup_tail+0x5b4/0x85c
       ip6_dst_lookup_flow+0x98/0x120
       rawv6_sendmsg+0x49c/0xc70
       inet_sendmsg+0x68/0x94
      
      Reproducer as following:
      Firstly, prepare conditions:
      $ip netns add ns1
      $ip netns add ns2
      $ip link add veth1 type veth peer name veth2
      $ip link set veth1 netns ns1
      $ip link set veth2 netns ns2
      $ip netns exec ns1 ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1
      $ip netns exec ns2 ip -6 addr add 2001:0db8:0:f101::2/64 dev veth2
      $ip netns exec ns1 ifconfig veth1 up
      $ip netns exec ns2 ifconfig veth2 up
      $ip netns exec ns1 ip -6 route add 2000::/64 dev veth1 metric 1
      $ip netns exec ns2 ip -6 route add 2001::/64 dev veth2 metric 1
      
      Secondly, execute the following two commands in two ssh windows
      respectively:
      $ip netns exec ns1 sh
      $while true; do ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1; ip -6 route add 2000::/64 dev veth1 metric 1; ping6 2000::2; done
      
      $ip netns exec ns1 sh
      $while true; do ip link set veth1 mtu 1000; ip link set veth1 mtu 1500; sleep 5; done
      
      It is because ip6_ptr has been assigned to NULL in addrconf_ifdown() firstly,
      then ip6_ignore_linkdown() accesses ip6_ptr directly without NULL check.
      
      	cpu0			cpu1
      fib6_table_lookup
      __find_rr_leaf
      			addrconf_notify [ NETDEV_CHANGEMTU ]
      			addrconf_ifdown
      			RCU_INIT_POINTER(dev->ip6_ptr, NULL)
      find_match
      ip6_ignore_linkdown
      
      So we can add NULL check for ip6_ptr before using in ip6_ignore_linkdown() to
      fix the null-ptr-deref bug.
      
      Fixes: dcd1f572 ("net/ipv6: Remove fib6_idev")
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20220728013307.656257-1-william.xuanziyang@huawei.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      
      Conflicts:
      	include/net/addrconf.h
      	net/ipv6/route.c
      
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      65db88fb
    • Jens Axboe's avatar
      io_uring: add missing item types for various requests · f0a1bfae
      Jens Axboe authored
      stable inclusion
      from stable-v5.10.125
      commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IM3T
      
      
      CVE: CVE-2022-2327
      
      --------------------------------
      
      Any read/write should grab current->nsproxy, denoted by IO_WQ_WORK_FILES
      as it refers to current->files as well, and connect and recv/recvmsg,
      send/sendmsg should grab current->fs which is denoted by IO_WQ_WORK_FS.
      
      No upstream commit exists for this issue.
      
      Reported-by: default avatarBing-Jhong Billy Jheng <billy@starlabs.sg>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      Conflicts:
      1. read/write already grab current->nsproxy, thus don't modified
      read/write related ops.
      2. 'work_flags' doesn't exist, io_op_def is using field 'needs_fs' to
      decide if 'current->fs' should be grabbed.
      Signed-off-by: default avatarYu Kuai <yukuai3@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      f0a1bfae
    • Eric Dumazet's avatar
      net/sched: cls_u32: fix possible leak in u32_init_knode() · f54991eb
      Eric Dumazet authored
      stable inclusion
      from stable-v4.19.240
      commit acff67727dff061f107def4c8c08bacde20d0d40
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5JNFK
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit ec5b0f605b105457f257f2870acad4a5d463984b ]
      
      While investigating a related syzbot report,
      I found that whenever call to tcf_exts_init()
      from u32_init_knode() is failing, we end up
      with an elevated refcount on ht->refcnt
      
      To avoid that, only increase the refcount after
      all possible errors have been evaluated.
      
      Fixes: b9a24bb7 ("net_sched: properly handle failure case of tcf_exts_init()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarLu Wei <luwei32@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      f54991eb
    • Eric Dumazet's avatar
      fq_codel: reject silly quantum parameters · 15e84ac5
      Eric Dumazet authored
      stable inclusion
      from stable-v4.19.207
      commit 7c113506163a1ec6157927428eddd80038d2916e
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5JPWX
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit c7c5e6ff533fe1f9afef7d2fa46678987a1335a7 ]
      
      syzbot found that forcing a big quantum attribute would crash hosts fast,
      essentially using this:
      
      tc qd replace dev eth0 root fq_codel quantum 4294967295
      
      This is because fq_codel_dequeue() would have to loop
      ~2^31 times in :
      
      	if (flow->deficit <= 0) {
      		flow->deficit += q->quantum;
      		list_move_tail(&flow->flowchain, &q->old_flows);
      		goto begin;
      	}
      
      SFQ max quantum is 2^19 (half a megabyte)
      Lets adopt a max quantum of one megabyte for FQ_CODEL.
      
      Fixes: 4b549a2e ("fq_codel: Fair Queue Codel AQM")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarLu Wei <luwei32@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      15e84ac5
    • Pavel Tikhomirov's avatar
      net: sched: sch_teql: fix null-pointer dereference · 92fadb6b
      Pavel Tikhomirov authored
      stable inclusion
      from stable-v4.19.187
      commit a9a7488979a7d0abfd30bc32f370b8e0c124db33
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5JPWC
      
      
      CVE: NA
      
      --------------------------------
      
      commit 1ffbc7ea91606e4abd10eb60de5367f1c86daf5e upstream.
      
      Reproduce:
      
        modprobe sch_teql
        tc qdisc add dev teql0 root teql0
      
      This leads to (for instance in Centos 7 VM) OOPS:
      
      [  532.366633] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      [  532.366733] IP: [<ffffffffc06124a8>] teql_destroy+0x18/0x100 [sch_teql]
      [  532.366825] PGD 80000001376d5067 PUD 137e37067 PMD 0
      [  532.366906] Oops: 0000 [#1] SMP
      [  532.366987] Modules linked in: sch_teql ...
      [  532.367945] CPU: 1 PID: 3026 Comm: tc Kdump: loaded Tainted: G               ------------ T 3.10.0-1062.7.1.el7.x86_64 #1
      [  532.368041] Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.2 04/01/2014
      [  532.368125] task: ffff8b7d37d31070 ti: ffff8b7c9fdbc000 task.ti: ffff8b7c9fdbc000
      [  532.368224] RIP: 0010:[<ffffffffc06124a8>]  [<ffffffffc06124a8>] teql_destroy+0x18/0x100 [sch_teql]
      [  532.368320] RSP: 0018:ffff8b7c9fdbf8e0  EFLAGS: 00010286
      [  532.368394] RAX: ffffffffc0612490 RBX: ffff8b7cb1565e00 RCX: ffff8b7d35ba2000
      [  532.368476] RDX: ffff8b7d35ba2000 RSI: 0000000000000000 RDI: ffff8b7cb1565e00
      [  532.368557] RBP: ffff8b7c9fdbf8f8 R08: ffff8b7d3fd1f140 R09: ffff8b7d3b001600
      [  532.368638] R10: ffff8b7d3b001600 R11: ffffffff84c7d65b R12: 00000000ffffffd8
      [  532.368719] R13: 0000000000008000 R14: ffff8b7d35ba2000 R15: ffff8b7c9fdbf9a8
      [  532.368800] FS:  00007f6a4e872740(0000) GS:ffff8b7d3fd00000(0000) knlGS:0000000000000000
      [  532.368885] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  532.368961] CR2: 00000000000000a8 CR3: 00000001396ee000 CR4: 00000000000206e0
      [  532.369046] Call Trace:
      [  532.369159]  [<ffffffff84c8192e>] qdisc_create+0x36e/0x450
      [  532.369268]  [<ffffffff846a9b49>] ? ns_capable+0x29/0x50
      [  532.369366]  [<ffffffff849afde2>] ? nla_parse+0x32/0x120
      [  532.369442]  [<ffffffff84c81b4c>] tc_modify_qdisc+0x13c/0x610
      [  532.371508]  [<ffffffff84c693e7>] rtnetlink_rcv_msg+0xa7/0x260
      [  532.372668]  [<ffffffff84907b65>] ? sock_has_perm+0x75/0x90
      [  532.373790]  [<ffffffff84c69340>] ? rtnl_newlink+0x890/0x890
      [  532.374914]  [<ffffffff84c8da7b>] netlink_rcv_skb+0xab/0xc0
      [  532.376055]  [<ffffffff84c63708>] rtnetlink_rcv+0x28/0x30
      [  532.377204]  [<ffffffff84c8d400>] netlink_unicast+0x170/0x210
      [  532.378333]  [<ffffffff84c8d7a8>] netlink_sendmsg+0x308/0x420
      [  532.379465]  [<ffffffff84c2f3a6>] sock_sendmsg+0xb6/0xf0
      [  532.380710]  [<ffffffffc034a56e>] ? __xfs_filemap_fault+0x8e/0x1d0 [xfs]
      [  532.381868]  [<ffffffffc034a75c>] ? xfs_filemap_fault+0x2c/0x30 [xfs]
      [  532.383037]  [<ffffffff847ec23a>] ? __do_fault.isra.61+0x8a/0x100
      [  532.384144]  [<ffffffff84c30269>] ___sys_sendmsg+0x3e9/0x400
      [  532.385268]  [<ffffffff847f3fad>] ? handle_mm_fault+0x39d/0x9b0
      [  532.386387]  [<ffffffff84d88678>] ? __do_page_fault+0x238/0x500
      [  532.387472]  [<ffffffff84c31921>] __sys_sendmsg+0x51/0x90
      [  532.388560]  [<ffffffff84c31972>] SyS_sendmsg+0x12/0x20
      [  532.389636]  [<ffffffff84d8dede>] system_call_fastpath+0x25/0x2a
      [  532.390704]  [<ffffffff84d8de21>] ? system_call_after_swapgs+0xae/0x146
      [  532.391753] Code: 00 00 00 00 00 00 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b b7 48 01 00 00 48 89 fb <48> 8b 8e a8 00 00 00 48 85 c9 74 43 48 89 ca eb 0f 0f 1f 80 00
      [  532.394036] RIP  [<ffffffffc06124a8>] teql_destroy+0x18/0x100 [sch_teql]
      [  532.395127]  RSP <ffff8b7c9fdbf8e0>
      [  532.396179] CR2: 00000000000000a8
      
      Null pointer dereference happens on master->slaves dereference in
      teql_destroy() as master is null-pointer.
      
      When qdisc_create() calls teql_qdisc_init() it imediately fails after
      check "if (m->dev == dev)" because both devices are teql0, and it does
      not set qdisc_priv(sch)->m leaving it zero on error path, then
      qdisc_create() imediately calls teql_destroy() which does not expect
      zero master pointer and we get OOPS.
      
      Fixes: 87b60cfa ("net_sched: fix error recovery at qdisc creation")
      Signed-off-by: default avatarPavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLu Wei <luwei32@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      92fadb6b
  4. Aug 04, 2022