1. 07 8月, 2023 1 次提交
  2. 03 8月, 2023 4 次提交
    • O
      !1625 Fix host zero page refcount overflow caused by kvm · e25d3df9
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from: Lei Chen <lei.chen@smartx.com>
      https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YBB4FWVDSAGSXOH4VTUKE6MMDOJWYADW/ 
      v2:
      1. using full commit id instead of abbrevation
      2. fix wrong mainline tag
      
      Sean Christopherson (1):
        KVM: Don't set Accessed/Dirty bits for ZERO_PAGE
      
      Zhuang Yanying (1):
        KVM: fix overflow of zero page refcount with ksm running
      
      
      -- 
      2.34.1
       
      https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue 
       
      Link:https://gitee.com/openeuler/kernel/pulls/1625 
      
      Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
      Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
      e25d3df9
    • O
      !1595 net: nfc: Fix CVE-2023-3863 · 35d90a85
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
      https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/H6ZQ55XGUXRWXUV5UOR5EIVMPTK4H3Z2/ 
      Backport CVE-2023-3863 fix commits.
      
      Aditya Pakki (1):
        nfc: Fix to check for kmemdup failure
      
      Krzysztof Kozlowski (2):
        nfc: llcp: nullify llcp_sock->dev on connect() error paths
        nfc: llcp: simplify llcp_sock_connect() error paths
      
      Lin Ma (1):
        net: nfc: Fix use-after-free caused by nfc_llcp_find_local
      
      
      -- 
      2.25.1
       
      https://gitee.com/src-openeuler/kernel/issues/I7NLJR 
       
      Link:https://gitee.com/openeuler/kernel/pulls/1595 
      
      Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
      Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 
      35d90a85
    • S
      KVM: Don't set Accessed/Dirty bits for ZERO_PAGE · 4addcc70
      Sean Christopherson 提交于
      mainline inclusion
      from mainline-v6.0-rc1
      commit a1040b0d
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue
      CVE: NA
      
      --------------------------------
      
      Don't set Accessed/Dirty bits for a struct page with PG_reserved set,
      i.e. don't set A/D bits for the ZERO_PAGE.  The ZERO_PAGE (or pages
      depending on the architecture) should obviously never be written, and
      similarly there's no point in marking it accessed as the page will never
      be swapped out or reclaimed.  The comment in page-flags.h is quite clear
      that PG_reserved pages should be managed only by their owner, and
      strictly following that mandate also simplifies KVM's logic.
      
      Fixes: 7df003c8 ("KVM: fix overflow of zero page refcount with ksm running")
      Signed-off-by: NSean Christopherson <seanjc@google.com>
      Message-Id: <20220429010416.2788472-4-seanjc@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NLei Chen <lei.chen@smartx.com>
      4addcc70
    • Z
      KVM: fix overflow of zero page refcount with ksm running · 2996491c
      Zhuang Yanying 提交于
      mainline inclusion
      from mainline-v5.6-rc1
      commit 7df003c8
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue
      CVE: NA
      
      --------------------------------
      
      We are testing Virtual Machine with KSM on v5.4-rc2 kernel,
      and found the zero_page refcount overflow.
      The cause of refcount overflow is increased in try_async_pf
      (get_user_page) without being decreased in mmu_set_spte()
      while handling ept violation.
      In kvm_release_pfn_clean(), only unreserved page will call
      put_page. However, zero page is reserved.
      So, as well as creating and destroy vm, the refcount of
      zero page will continue to increase until it overflows.
      
      step1:
      echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan
      echo 1 > /sys/kernel/pages_to_scan/run
      echo 1 > /sys/kernel/pages_to_scan/use_zero_pages
      
      step2:
      just create several normal qemu kvm vms.
      And destroy it after 10s.
      Repeat this action all the time.
      
      After a long period of time, all domains hang because
      of the refcount of zero page overflow.
      
      Qemu print error log as follow:
       …
       error: kvm run failed Bad address
       EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd
       ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4
       EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
       ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
       SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
       LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
       TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
       GDT=     000f7070 00000037
       IDT=     000f70ae 00000000
       CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
       DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
       DR6=00000000ffff0ff0 DR7=0000000000000400
       EFER=0000000000000000
       Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04
       …
      
      Meanwhile, a kernel warning is departed.
      
       [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30
       [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G           OE     5.2.0-rc2 #5
       [40914.836415] RIP: 0010:try_get_page+0x1f/0x30
       [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0
       0 00 00 00 48 8b 47 08 a8
       [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286
       [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000
       [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440
       [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000
       [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8
       [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440
       [40914.836423] FS:  00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000
       [40914.836425] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0
       [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       [40914.836428] Call Trace:
       [40914.836433]  follow_page_pte+0x302/0x47b
       [40914.836437]  __get_user_pages+0xf1/0x7d0
       [40914.836441]  ? irq_work_queue+0x9/0x70
       [40914.836443]  get_user_pages_unlocked+0x13f/0x1e0
       [40914.836469]  __gfn_to_pfn_memslot+0x10e/0x400 [kvm]
       [40914.836486]  try_async_pf+0x87/0x240 [kvm]
       [40914.836503]  tdp_page_fault+0x139/0x270 [kvm]
       [40914.836523]  kvm_mmu_page_fault+0x76/0x5e0 [kvm]
       [40914.836588]  vcpu_enter_guest+0xb45/0x1570 [kvm]
       [40914.836632]  kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm]
       [40914.836645]  kvm_vcpu_ioctl+0x26e/0x5d0 [kvm]
       [40914.836650]  do_vfs_ioctl+0xa9/0x620
       [40914.836653]  ksys_ioctl+0x60/0x90
       [40914.836654]  __x64_sys_ioctl+0x16/0x20
       [40914.836658]  do_syscall_64+0x5b/0x180
       [40914.836664]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
       [40914.836666] RIP: 0033:0x7fb61cb6bfc7
      Signed-off-by: NLinFeng <linfeng23@huawei.com>
      Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NLei Chen <lei.chen@smartx.com>
      2996491c
  3. 31 7月, 2023 4 次提交
    • L
      net: nfc: Fix use-after-free caused by nfc_llcp_find_local · 7c9ed847
      Lin Ma 提交于
      mainline inclusion
      from mainline-v6.5-rc1
      commit 6709d4b7bc2e079241fdef15d1160581c5261c10
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR
      CVE: CVE-2023-3863
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6709d4b7bc2e079241fdef15d1160581c5261c10
      
      ---------------------------
      
      This commit fixes several use-after-free that caused by function
      nfc_llcp_find_local(). For example, one UAF can happen when below buggy
      time window occurs.
      
      // nfc_genl_llc_get_params   | // nfc_unregister_device
                                   |
      dev = nfc_get_device(idx);   | device_lock(...)
      if (!dev)                    | dev->shutting_down = true;
          return -ENODEV;          | device_unlock(...);
                                   |
      device_lock(...);            |   // nfc_llcp_unregister_device
                                   |   nfc_llcp_find_local()
      nfc_llcp_find_local(...);    |
                                   |   local_cleanup()
      if (!local) {                |
          rc = -ENODEV;            |     // nfc_llcp_local_put
          goto exit;               |     kref_put(.., local_release)
      }                            |
                                   |       // local_release
                                   |       list_del(&local->list)
        // nfc_genl_send_params    |       kfree()
        local->dev->idx !!!UAF!!!  |
                                   |
      
      and the crash trace for the one of the discussed UAF like:
      
      BUG: KASAN: slab-use-after-free in nfc_genl_llc_get_params+0x72f/0x780  net/nfc/netlink.c:1045
      Read of size 8 at addr ffff888105b0e410 by task 20114
      
      Call Trace:
       <TASK>
       __dump_stack  lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0x72/0xa0  lib/dump_stack.c:106
       print_address_description  mm/kasan/report.c:319 [inline]
       print_report+0xcc/0x620  mm/kasan/report.c:430
       kasan_report+0xb2/0xe0  mm/kasan/report.c:536
       nfc_genl_send_params  net/nfc/netlink.c:999 [inline]
       nfc_genl_llc_get_params+0x72f/0x780  net/nfc/netlink.c:1045
       genl_family_rcv_msg_doit.isra.0+0x1ee/0x2e0  net/netlink/genetlink.c:968
       genl_family_rcv_msg  net/netlink/genetlink.c:1048 [inline]
       genl_rcv_msg+0x503/0x7d0  net/netlink/genetlink.c:1065
       netlink_rcv_skb+0x161/0x430  net/netlink/af_netlink.c:2548
       genl_rcv+0x28/0x40  net/netlink/genetlink.c:1076
       netlink_unicast_kernel  net/netlink/af_netlink.c:1339 [inline]
       netlink_unicast+0x644/0x900  net/netlink/af_netlink.c:1365
       netlink_sendmsg+0x934/0xe70  net/netlink/af_netlink.c:1913
       sock_sendmsg_nosec  net/socket.c:724 [inline]
       sock_sendmsg+0x1b6/0x200  net/socket.c:747
       ____sys_sendmsg+0x6e9/0x890  net/socket.c:2501
       ___sys_sendmsg+0x110/0x1b0  net/socket.c:2555
       __sys_sendmsg+0xf7/0x1d0  net/socket.c:2584
       do_syscall_x64  arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3f/0x90  arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      RIP: 0033:0x7f34640a2389
      RSP: 002b:00007f3463415168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f34641c1f80 RCX: 00007f34640a2389
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000006
      RBP: 00007f34640ed493 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffe38449ecf R14: 00007f3463415300 R15: 0000000000022000
       </TASK>
      
      Allocated by task 20116:
       kasan_save_stack+0x22/0x50  mm/kasan/common.c:45
       kasan_set_track+0x25/0x30  mm/kasan/common.c:52
       ____kasan_kmalloc  mm/kasan/common.c:374 [inline]
       __kasan_kmalloc+0x7f/0x90  mm/kasan/common.c:383
       kmalloc  include/linux/slab.h:580 [inline]
       kzalloc  include/linux/slab.h:720 [inline]
       nfc_llcp_register_device+0x49/0xa40  net/nfc/llcp_core.c:1567
       nfc_register_device+0x61/0x260  net/nfc/core.c:1124
       nci_register_device+0x776/0xb20  net/nfc/nci/core.c:1257
       virtual_ncidev_open+0x147/0x230  drivers/nfc/virtual_ncidev.c:148
       misc_open+0x379/0x4a0  drivers/char/misc.c:165
       chrdev_open+0x26c/0x780  fs/char_dev.c:414
       do_dentry_open+0x6c4/0x12a0  fs/open.c:920
       do_open  fs/namei.c:3560 [inline]
       path_openat+0x24fe/0x37e0  fs/namei.c:3715
       do_filp_open+0x1ba/0x410  fs/namei.c:3742
       do_sys_openat2+0x171/0x4c0  fs/open.c:1356
       do_sys_open  fs/open.c:1372 [inline]
       __do_sys_openat  fs/open.c:1388 [inline]
       __se_sys_openat  fs/open.c:1383 [inline]
       __x64_sys_openat+0x143/0x200  fs/open.c:1383
       do_syscall_x64  arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3f/0x90  arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      Freed by task 20115:
       kasan_save_stack+0x22/0x50  mm/kasan/common.c:45
       kasan_set_track+0x25/0x30  mm/kasan/common.c:52
       kasan_save_free_info+0x2e/0x50  mm/kasan/generic.c:521
       ____kasan_slab_free  mm/kasan/common.c:236 [inline]
       ____kasan_slab_free  mm/kasan/common.c:200 [inline]
       __kasan_slab_free+0x10a/0x190  mm/kasan/common.c:244
       kasan_slab_free  include/linux/kasan.h:162 [inline]
       slab_free_hook  mm/slub.c:1781 [inline]
       slab_free_freelist_hook  mm/slub.c:1807 [inline]
       slab_free  mm/slub.c:3787 [inline]
       __kmem_cache_free+0x7a/0x190  mm/slub.c:3800
       local_release  net/nfc/llcp_core.c:174 [inline]
       kref_put  include/linux/kref.h:65 [inline]
       nfc_llcp_local_put  net/nfc/llcp_core.c:182 [inline]
       nfc_llcp_local_put  net/nfc/llcp_core.c:177 [inline]
       nfc_llcp_unregister_device+0x206/0x290  net/nfc/llcp_core.c:1620
       nfc_unregister_device+0x160/0x1d0  net/nfc/core.c:1179
       virtual_ncidev_close+0x52/0xa0  drivers/nfc/virtual_ncidev.c:163
       __fput+0x252/0xa20  fs/file_table.c:321
       task_work_run+0x174/0x270  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+0x108/0x110  kernel/entry/common.c:204
       __syscall_exit_to_user_mode_work  kernel/entry/common.c:286 [inline]
       syscall_exit_to_user_mode+0x21/0x50  kernel/entry/common.c:297
       do_syscall_64+0x4c/0x90  arch/x86/entry/common.c:86
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      Last potentially related work creation:
       kasan_save_stack+0x22/0x50  mm/kasan/common.c:45
       __kasan_record_aux_stack+0x95/0xb0  mm/kasan/generic.c:491
       kvfree_call_rcu+0x29/0xa80  kernel/rcu/tree.c:3328
       drop_sysctl_table+0x3be/0x4e0  fs/proc/proc_sysctl.c:1735
       unregister_sysctl_table.part.0+0x9c/0x190  fs/proc/proc_sysctl.c:1773
       unregister_sysctl_table+0x24/0x30  fs/proc/proc_sysctl.c:1753
       neigh_sysctl_unregister+0x5f/0x80  net/core/neighbour.c:3895
       addrconf_notify+0x140/0x17b0  net/ipv6/addrconf.c:3684
       notifier_call_chain+0xbe/0x210  kernel/notifier.c:87
       call_netdevice_notifiers_info+0xb5/0x150  net/core/dev.c:1937
       call_netdevice_notifiers_extack  net/core/dev.c:1975 [inline]
       call_netdevice_notifiers  net/core/dev.c:1989 [inline]
       dev_change_name+0x3c3/0x870  net/core/dev.c:1211
       dev_ifsioc+0x800/0xf70  net/core/dev_ioctl.c:376
       dev_ioctl+0x3d9/0xf80  net/core/dev_ioctl.c:542
       sock_do_ioctl+0x160/0x260  net/socket.c:1213
       sock_ioctl+0x3f9/0x670  net/socket.c:1316
       vfs_ioctl  fs/ioctl.c:51 [inline]
       __do_sys_ioctl  fs/ioctl.c:870 [inline]
       __se_sys_ioctl  fs/ioctl.c:856 [inline]
       __x64_sys_ioctl+0x19e/0x210  fs/ioctl.c:856
       do_syscall_x64  arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3f/0x90  arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      The buggy address belongs to the object at ffff888105b0e400
       which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 16 bytes inside of
       freed 1024-byte region [ffff888105b0e400, ffff888105b0e800)
      
      The buggy address belongs to the physical page:
      head:ffffea000416c200 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
      flags: 0x200000000010200(slab|head|node=0|zone=2)
      raw: 0200000000010200 ffff8881000430c0 ffffea00044c7010 ffffea0004510e10
      raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888105b0e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888105b0e380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff888105b0e400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                               ^
       ffff888105b0e480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888105b0e500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      In summary, this patch solves those use-after-free by
      
      1. Re-implement the nfc_llcp_find_local(). The current version does not
      grab the reference when getting the local from the linked list.  For
      example, the llcp_sock_bind() gets the reference like below:
      
      // llcp_sock_bind()
      
          local = nfc_llcp_find_local(dev); // A
          ..... \
                 | raceable
          ..... /
          llcp_sock->local = nfc_llcp_local_get(local); // B
      
      There is an apparent race window that one can  drop the reference
      and free the local object fetched in (A) before (B) gets the reference.
      
      2. Some callers of the nfc_llcp_find_local() do not grab the reference
      at all. For example, the nfc_genl_llc_{{get/set}_params/sdreq} functions.
      We add the nfc_llcp_local_put() for them. Moreover, we add the necessary
      error handling function to put the reference.
      
      3. Add the nfc_llcp_remove_local() helper. The local object is removed
      from the linked list in local_release() when all reference is gone. This
      patch removes it when nfc_llcp_unregister_device() is called.
      
      Therefore, every caller of nfc_llcp_find_local() will get a reference
      even when the nfc_llcp_unregister_device() is called. This promises no
      use-after-free for the local object is ever possible.
      
      Fixes: 52feb444 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support")
      Fixes: c7aa1225 ("NFC: Take a reference on the LLCP local pointer when creating a socket")
      Signed-off-by: NLin Ma <linma@zju.edu.cn>
      Reviewed-by: NSimon Horman <simon.horman@corigine.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      7c9ed847
    • K
      nfc: llcp: simplify llcp_sock_connect() error paths · e42d68bb
      Krzysztof Kozlowski 提交于
      mainline inclusion
      from mainline-v5.18-rc1
      commit ec10fd15
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR
      CVE: CVE-2023-3863
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec10fd154d934cc4195da3cbd017a12817b41d51
      
      ---------------------------
      
      The llcp_sock_connect() error paths were using a mixed way of central
      exit (goto) and cleanup
      Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      e42d68bb
    • K
      nfc: llcp: nullify llcp_sock->dev on connect() error paths · d966f783
      Krzysztof Kozlowski 提交于
      mainline inclusion
      from mainline-v5.18-rc1
      commit 13a3585b
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR
      CVE: CVE-2023-3863
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a3585b264bfeba018941a713b8d7fc9b8221a2
      
      ---------------------------
      
      Nullify the llcp_sock->dev on llcp_sock_connect() error paths,
      symmetrically to the code llcp_sock_bind().  The non-NULL value of
      llcp_sock->dev is used in a few places to check whether the socket is
      still valid.
      
      There was no particular issue observed with missing NULL assignment in
      connect() error path, however a similar case - in the bind() error path
      - was triggereable.  That one was fixed in commit 4ac06a1e ("nfc:
      fix NULL ptr dereference in llcp_sock_getname() after failed connect"),
      so the change here seems logical as well.
      Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      d966f783
    • A
      nfc: Fix to check for kmemdup failure · 88a94b54
      Aditya Pakki 提交于
      mainline inclusion
      from mainline-v5.1-rc3
      commit d7737d42
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR
      CVE: CVE-2023-3863
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7737d4257459ca8921ff911c88937be1a11ea9d
      
      ---------------------------
      
      In case of kmemdup failure while setting the service name the patch
      returns -ENOMEM upstream for processing.
      Signed-off-by: NAditya Pakki <pakki001@umn.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Conflicts:
      	net/nfc/llcp_sock.c
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      88a94b54
  4. 29 7月, 2023 11 次提交
  5. 28 7月, 2023 2 次提交
  6. 27 7月, 2023 3 次提交
  7. 25 7月, 2023 4 次提交
  8. 24 7月, 2023 2 次提交
  9. 20 7月, 2023 4 次提交
  10. 19 7月, 2023 3 次提交
    • L
      pmu: remove uncore code for Zhaoxin Platform · e0b206d1
      leoliu-oc 提交于
      zhaoxin inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7LXCE
      CVE: NA
      
      --------------------------------------------
      
      There are some issues that need to be resolved for Zhaoxin Platform.
      So remove Zhaoxin uncore code first.
      Signed-off-by: Nleoliu-oc <leoliu-oc@zhaoxin.com>
      e0b206d1
    • Z
      ipv6/addrconf: fix a potential refcount underflow for idev · fd2ee0ae
      Ziyang Xuan 提交于
      mainline inclusion
      from mainline-v6.5-rc2
      commit 06a0716949c22e2aefb648526580671197151acc
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7M991
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06a0716949c22e2aefb648526580671197151acc
      
      ---------------------------
      
      Now in addrconf_mod_rs_timer(), reference idev depends on whether
      rs_timer is not pending. Then modify rs_timer timeout.
      
      There is a time gap in [1], during which if the pending rs_timer
      becomes not pending. It will miss to hold idev, but the rs_timer
      is activated. Thus rs_timer callback function addrconf_rs_timer()
      will be executed and put idev later without holding idev. A refcount
      underflow issue for idev can be caused by this.
      
      	if (!timer_pending(&idev->rs_timer))
      		in6_dev_hold(idev);
      		  <--------------[1]
      	mod_timer(&idev->rs_timer, jiffies + when);
      
      To fix the issue, hold idev if mod_timer() return 0.
      
      Fixes: b7b1bfce ("ipv6: split duplicate address detection and router solicitation timer")
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      fd2ee0ae
    • T
      netfilter: nf_tables: prevent OOB access in nft_byteorder_eval · 2aafe85a
      Thadeu Lima de Souza Cascardo 提交于
      mainline inclusion
      from mainline-v6.5-rc2
      commit caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR1
      CVE: CVE-2023-35001
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd
      
      ---------------------------
      
      When evaluating byteorder expressions with size 2, a union with 32-bit and
      16-bit members is used. Since the 16-bit members are aligned to 32-bit,
      the array accesses will be out-of-bounds.
      
      It may lead to a stack-out-of-bounds access like the one below:
      
      [   23.095215] ==================================================================
      [   23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320
      [   23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115
      [   23.096358]
      [   23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413
      [   23.096770] Call Trace:
      [   23.096910]  <IRQ>
      [   23.097030]  dump_stack_lvl+0x60/0xc0
      [   23.097218]  print_report+0xcf/0x630
      [   23.097388]  ? nft_byteorder_eval+0x13c/0x320
      [   23.097577]  ? kasan_addr_to_slab+0xd/0xc0
      [   23.097760]  ? nft_byteorder_eval+0x13c/0x320
      [   23.097949]  kasan_report+0xc9/0x110
      [   23.098106]  ? nft_byteorder_eval+0x13c/0x320
      [   23.098298]  __asan_load2+0x83/0xd0
      [   23.098453]  nft_byteorder_eval+0x13c/0x320
      [   23.098659]  nft_do_chain+0x1c8/0xc50
      [   23.098852]  ? __pfx_nft_do_chain+0x10/0x10
      [   23.099078]  ? __kasan_check_read+0x11/0x20
      [   23.099295]  ? __pfx___lock_acquire+0x10/0x10
      [   23.099535]  ? __pfx___lock_acquire+0x10/0x10
      [   23.099745]  ? __kasan_check_read+0x11/0x20
      [   23.099929]  nft_do_chain_ipv4+0xfe/0x140
      [   23.100105]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
      [   23.100327]  ? lock_release+0x204/0x400
      [   23.100515]  ? nf_hook.constprop.0+0x340/0x550
      [   23.100779]  nf_hook_slow+0x6c/0x100
      [   23.100977]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
      [   23.101223]  nf_hook.constprop.0+0x334/0x550
      [   23.101443]  ? __pfx_ip_local_deliver_finish+0x10/0x10
      [   23.101677]  ? __pfx_nf_hook.constprop.0+0x10/0x10
      [   23.101882]  ? __pfx_ip_rcv_finish+0x10/0x10
      [   23.102071]  ? __pfx_ip_local_deliver_finish+0x10/0x10
      [   23.102291]  ? rcu_read_lock_held+0x4b/0x70
      [   23.102481]  ip_local_deliver+0xbb/0x110
      [   23.102665]  ? __pfx_ip_rcv+0x10/0x10
      [   23.102839]  ip_rcv+0x199/0x2a0
      [   23.102980]  ? __pfx_ip_rcv+0x10/0x10
      [   23.103140]  __netif_receive_skb_one_core+0x13e/0x150
      [   23.103362]  ? __pfx___netif_receive_skb_one_core+0x10/0x10
      [   23.103647]  ? mark_held_locks+0x48/0xa0
      [   23.103819]  ? process_backlog+0x36c/0x380
      [   23.103999]  __netif_receive_skb+0x23/0xc0
      [   23.104179]  process_backlog+0x91/0x380
      [   23.104350]  __napi_poll.constprop.0+0x66/0x360
      [   23.104589]  ? net_rx_action+0x1cb/0x610
      [   23.104811]  net_rx_action+0x33e/0x610
      [   23.105024]  ? _raw_spin_unlock+0x23/0x50
      [   23.105257]  ? __pfx_net_rx_action+0x10/0x10
      [   23.105485]  ? mark_held_locks+0x48/0xa0
      [   23.105741]  __do_softirq+0xfa/0x5ab
      [   23.105956]  ? __dev_queue_xmit+0x765/0x1c00
      [   23.106193]  do_softirq.part.0+0x49/0xc0
      [   23.106423]  </IRQ>
      [   23.106547]  <TASK>
      [   23.106670]  __local_bh_enable_ip+0xf5/0x120
      [   23.106903]  __dev_queue_xmit+0x789/0x1c00
      [   23.107131]  ? __pfx___dev_queue_xmit+0x10/0x10
      [   23.107381]  ? find_held_lock+0x8e/0xb0
      [   23.107585]  ? lock_release+0x204/0x400
      [   23.107798]  ? neigh_resolve_output+0x185/0x350
      [   23.108049]  ? mark_held_locks+0x48/0xa0
      [   23.108265]  ? neigh_resolve_output+0x185/0x350
      [   23.108514]  neigh_resolve_output+0x246/0x350
      [   23.108753]  ? neigh_resolve_output+0x246/0x350
      [   23.109003]  ip_finish_output2+0x3c3/0x10b0
      [   23.109250]  ? __pfx_ip_finish_output2+0x10/0x10
      [   23.109510]  ? __pfx_nf_hook+0x10/0x10
      [   23.109732]  __ip_finish_output+0x217/0x390
      [   23.109978]  ip_finish_output+0x2f/0x130
      [   23.110207]  ip_output+0xc9/0x170
      [   23.110404]  ip_push_pending_frames+0x1a0/0x240
      [   23.110652]  raw_sendmsg+0x102e/0x19e0
      [   23.110871]  ? __pfx_raw_sendmsg+0x10/0x10
      [   23.111093]  ? lock_release+0x204/0x400
      [   23.111304]  ? __mod_lruvec_page_state+0x148/0x330
      [   23.111567]  ? find_held_lock+0x8e/0xb0
      [   23.111777]  ? find_held_lock+0x8e/0xb0
      [   23.111993]  ? __rcu_read_unlock+0x7c/0x2f0
      [   23.112225]  ? aa_sk_perm+0x18a/0x550
      [   23.112431]  ? filemap_map_pages+0x4f1/0x900
      [   23.112665]  ? __pfx_aa_sk_perm+0x10/0x10
      [   23.112880]  ? find_held_lock+0x8e/0xb0
      [   23.113098]  inet_sendmsg+0xa0/0xb0
      [   23.113297]  ? inet_sendmsg+0xa0/0xb0
      [   23.113500]  ? __pfx_inet_sendmsg+0x10/0x10
      [   23.113727]  sock_sendmsg+0xf4/0x100
      [   23.113924]  ? move_addr_to_kernel.part.0+0x4f/0xa0
      [   23.114190]  __sys_sendto+0x1d4/0x290
      [   23.114391]  ? __pfx___sys_sendto+0x10/0x10
      [   23.114621]  ? __pfx_mark_lock.part.0+0x10/0x10
      [   23.114869]  ? lock_release+0x204/0x400
      [   23.115076]  ? find_held_lock+0x8e/0xb0
      [   23.115287]  ? rcu_is_watching+0x23/0x60
      [   23.115503]  ? __rseq_handle_notify_resume+0x6e2/0x860
      [   23.115778]  ? __kasan_check_write+0x14/0x30
      [   23.116008]  ? blkcg_maybe_throttle_current+0x8d/0x770
      [   23.116285]  ? mark_held_locks+0x28/0xa0
      [   23.116503]  ? do_syscall_64+0x37/0x90
      [   23.116713]  __x64_sys_sendto+0x7f/0xb0
      [   23.116924]  do_syscall_64+0x59/0x90
      [   23.117123]  ? irqentry_exit_to_user_mode+0x25/0x30
      [   23.117387]  ? irqentry_exit+0x77/0xb0
      [   23.117593]  ? exc_page_fault+0x92/0x140
      [   23.117806]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      [   23.118081] RIP: 0033:0x7f744aee2bba
      [   23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
      [   23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [   23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba
      [   23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003
      [   23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010
      [   23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
      [   23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0
      [   23.121617]  </TASK>
      [   23.121749]
      [   23.121845] The buggy address belongs to the virtual mapping at
      [   23.121845]  [ffffc90000000000, ffffc90000009000) created by:
      [   23.121845]  irq_init_percpu_irqstack+0x1cf/0x270
      [   23.122707]
      [   23.122803] The buggy address belongs to the physical page:
      [   23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09
      [   23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff)
      [   23.123998] page_type: 0xffffffff()
      [   23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000
      [   23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
      [   23.125023] page dumped because: kasan: bad access detected
      [   23.125326]
      [   23.125421] Memory state around the buggy address:
      [   23.125682]  ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   23.126072]  ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00
      [   23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00
      [   23.126840]                                               ^
      [   23.127138]  ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3
      [   23.127522]  ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
      [   23.127906] ==================================================================
      [   23.128324] Disabling lock debugging due to kernel taint
      
      Using simple s16 pointers for the 16-bit accesses fixes the problem. For
      the 32-bit accesses, src and dst can be used directly.
      
      Fixes: 96518518 ("netfilter: add nftables")
      Cc: stable@vger.kernel.org
      Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Reviewed-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      2aafe85a
  11. 18 7月, 2023 2 次提交