Skip to content
Snippets Groups Projects
  1. Oct 31, 2022
  2. Oct 29, 2022
    • Ryusuke Konishi's avatar
      nilfs2: fix leak of nilfs_root in case of writer thread creation failure · 8ad0934c
      Ryusuke Konishi authored
      mainline inclusion
      from mainline-v6.1-rc1
      commit d0d51a97063db4704a5ef6bc978dddab1636a306
      category: bugfix
      bugzilla: 187884, https://gitee.com/src-openeuler/kernel/issues/I5X2OB
      CVE: CVE-2022-3646
      
      --------------------------------
      
      If nilfs_attach_log_writer() failed to create a log writer thread, it
      frees a data structure of the log writer without any cleanup.  After
      commit e912a5b6 ("nilfs2: use root object to get ifile"), this causes
      a leak of struct nilfs_root, which started to leak an ifile metadata inode
      and a kobject on that struct.
      
      In addition, if the kernel is booted with panic_on_warn, the above
      ifile metadata inode leak will cause the following panic when the
      nilfs2 kernel module is removed:
      
        kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when
        called from nilfs_destroy_cachep+0x16/0x3a [nilfs2]
        WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140
        ...
        RIP: 0010...
      8ad0934c
    • Peilin Ye's avatar
      vsock: Fix memory leak in vsock_connect() · e6db4754
      Peilin Ye authored
      stable inclusion
      from stable-v4.19.256
      commit 2fc2a7767f661e6083f69588718cdf6f07cb9330
      category: bugfix
      bugzilla: 187891, https://gitee.com/src-openeuler/kernel/issues/I5WYLL
      CVE: CVE-2022-3629
      
      --------------------------------
      
      commit 7e97cfed9929eaabc41829c395eb0d1350fccb9d upstream.
      
      An O_NONBLOCK vsock_connect() request may try to reschedule
      @connect_work.  Imagine the following sequence of vsock_connect()
      requests:
      
        1. The 1st, non-blocking request schedules @connect_work, which will
           expire after 200 jiffies.  Socket state is now SS_CONNECTING;
      
        2. Later, the 2nd, blocking request gets interrupted by a signal after
           a few jiffies while waiting for the connection to be established.
           Socket state is back to SS_UNCONNECTED, but @connect_work is still
           pending, and will expire after 100 jiffies.
      
        3. Now, the 3rd, non-blocking request tries to schedule @connect_work
           again.  Since @connect_work is already scheduled,
           schedule_delayed...
      e6db4754
  3. Oct 27, 2022
  4. Oct 25, 2022
    • Jialiang Wang's avatar
      nfp: fix use-after-free in area_cache_get() · 187e173a
      Jialiang Wang authored
      mainline inclusion
      from mainline-v6.0-rc1
      commit 02e1a114fdb71e59ee6770294166c30d437bf86a
      category: bugfix
      bugzilla: 187867, https://gitee.com/src-openeuler/kernel/issues/I5W7B5
      CVE: CVE-2022-3545
      
      --------------------------------
      
      area_cache_get() is used to distribute cache->area and set cache->id,
       and if cache->id is not 0 and cache->area->kref refcount is 0, it will
       release the cache->area by nfp_cpp_area_release(). area_cache_get()
       set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
      
      But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
       is already set but the refcount is not increased as expected. At this
       time, calling the nfp_cpp_area_release() will cause use-after-free.
      
      To avoid the use-after-free, set cache->id after area_init() and
       nfp_cpp_area_acquire() complete successfully.
      
      Note: This vulnerability is triggerable by providing emulated device
       equipped with specified configuration.
      
       BUG: KASAN: use-after-free ...
    • Duoming Zhou's avatar
      mISDN: fix use-after-free bugs in l1oip timer handlers · 20fb5faf
      Duoming Zhou authored
      mainline inclusion
      from mainline-v6.1-rc1
      commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7YH
      
      
      CVE: CVE-2022-3565
      
      --------------------------------
      
      The l1oip_cleanup() traverses the l1oip_ilist and calls
      release_card() to cleanup module and stack. However,
      release_card() calls del_timer() to delete the timers
      such as keep_tl and timeout_tl. If the timer handler is
      running, the del_timer() will not stop it and result in
      UAF bugs. One of the processes is shown below:
      
          (cleanup routine)          |        (timer handler)
      release_card()                 | l1oip_timeout()
       ...                           |
       del_timer()                   | ...
       ...                           |
       kfree(hc) //FREE              |
                                     | hc->timeout_on = 0 //USE
      
      Fix by calling del_timer_sync() in release_card(), which
      makes sure the timer handlers have finished before the
      resources, such as l1oip and so on, have been deallocated.
      
      What's more, the hc->workq and hc->socket_thread can kick
      those timers right back in. We add a bool flag to show
      if card is released. Then, check this flag in hc->workq
      and hc->socket_thread.
      
      Fixes: 3712b42d ("Add layer1 over IP support")
      Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGUO Zihua <guozihua@huawei.com>
      Reviewed-by: default avatarGONG Ruiqi <gongruiqi1@huawei.com>
      Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      20fb5faf
    • Kuniyuki Iwashima's avatar
      tcp: Fix data races around icsk->icsk_af_ops. · 1ae8a44b
      Kuniyuki Iwashima authored
      mainline inclusion
      from mainline-v6.1-rc1
      commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7ZF
      
      
      CVE: CVE-2022-3566
      
      --------------------------------
      
      setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops
      under lock_sock(), but tcp_(get|set)sockopt() read it locklessly.  To
      avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE()
      for the reads and writes.
      
      Thanks to Eric Dumazet for providing the syzbot report:
      
      BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect
      
      write to 0xffff88813c624518 of 8 bytes by task 23936 on cpu 0:
      tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240
      __inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660
      inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724
      __sys_connect_file net/socket.c:1976 [inline]
      __sys_connect+0x197/0x1b0 net/socket.c:1993
      __do_sys_connect net/socket.c:2003 [inline]
      __se_sys_connect net/socket.c:2000 [inline]
      __x64_sys_connect+0x3d/0x50 net/socket.c:2000
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      read to 0xffff88813c624518 of 8 bytes by task 23937 on cpu 1:
      tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789
      sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585
      __sys_setsockopt+0x212/0x2b0 net/socket.c:2252
      __do_sys_setsockopt net/socket.c:2263 [inline]
      __se_sys_setsockopt net/socket.c:2260 [inline]
      __x64_sys_setsockopt+0x62/0x70 net/socket.c:2260
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      value changed: 0xffffffff8539af68 -> 0xffffffff8539aff8
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted
      6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0
      
      Hardware name: Google Google Compute Engine/Google Compute Engine,
      BIOS Google 08/26/2022
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Conflicts:
      	net/ipv4/tcp.c
      	net/ipv6/ipv6_sockglue.c
      	net/ipv6/tcp_ipv6.c
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      1ae8a44b
    • Maxim Mikityanskiy's avatar
      Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu · 1c1e7cf5
      Maxim Mikityanskiy authored
      mainline inclusion
      from bluetooth-next
      commit 89f9f3cb86b1c63badaf392a83dd661d56cc50b1
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7XW
      CVE: CVE-2022-3564
      
      --------------------------------
      
      Fix the race condition between the following two flows that run in
      parallel:
      
      1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
         __sock_queue_rcv_skb.
      
      2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
      
      An SKB can be queued by the first flow and immediately dequeued and
      freed by the second flow, therefore the callers of l2cap_reassemble_sdu
      can't use the SKB after that function returns. However, some places
      continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
      short time after l2cap_reassemble_sdu returns, leading to a
      use-after-free condition (the stack trace is below, line numbers for
      kernel 5.19.8).
      
      Fix it by keeping a local copy of struct l2cap_ctrl.
      
      BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
      Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
      
      Workqueue: hci0 hci_rx_work [bluetooth]
      Call Trace:
       <TASK>
       dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
       print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
       ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
       ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
       ret_from_fork (arch/x86/entry/entry_64.S:306)
       </TASK>
      
      Allocated by task 43169:
       kasan_save_stack (mm/kasan/common.c:39)
       __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
       kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
       __alloc_skb (net/core/skbuff.c:414)
       l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
       l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
       hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
       process_one_work (kernel/workqueue.c:2289)
       worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
       kthread (kernel/kthread.c:376)
       ret_from_fork (arch/x86/entry/entry_64.S:306)
      
      Freed by task 27920:
       kasan_save_stack (mm/kasan/common.c:39)
       kasan_set_track (mm/kasan/common.c:45)
       kasan_set_free_info (mm/kasan/generic.c:372)
       ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
       slab_free_freelist_hook (mm/slub.c:1780)
       kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
       skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
       bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
       l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
       sock_read_iter (net/socket.c:1087)
       new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
       vfs_read (fs/read_write.c:482)
       ksys_read (fs/read_write.c:620)
       do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
       entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
      
      Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
      
      
      Fixes: d2a7ac5d ("Bluetooth: Add the ERTM receive state machine")
      Fixes: 4b51dae9 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
      Signed-off-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      
      conflicts:
      	net/bluetooth/l2cap_core.c
      
      Signed-off-by: default avatarXia Longlong <xialonglong1@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      1c1e7cf5
    • openeuler-ci-bot's avatar
      !134 scsi: megaraid_sas: Add support for MegaRAID Aero controllers · f0db3aa1
      openeuler-ci-bot authored
      Merge Pull Request from: @babyihc 
       
      This PR is cherry-pick from upstream "scsi: megaraid_sas: Add support for MegaRAID Aero controllers"
      
      Upstream patch:
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=469f72ddc618d0afe05176b18ae6ebefb1fc6fe2 
       
      Link:https://gitee.com/openeuler/kernel/pulls/134
      
       
      Reviewed-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      Signed-off-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      f0db3aa1
    • openeuler-ci-bot's avatar
      !138 vfio-pci: Mask cap zero · 4a152517
      openeuler-ci-bot authored
      Merge Pull Request from: @babyihc 
       
      This PR is cherry-pick from upstream "vfio-pci: Mask cap zero"
      
      Upstream patch:
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc138db1b96264b9c1779cf18d5a3b186aa90066
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/138
      
       
      Reviewed-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      Signed-off-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      4a152517
  5. Oct 24, 2022
  6. Oct 21, 2022
  7. Oct 20, 2022
    • Kuniyuki Iwashima's avatar
      tcp/udp: Fix memory leak in ipv6_renew_options(). · 0724868f
      Kuniyuki Iwashima authored
      mainline inclusion
      from mainline-v6.1-rc1
      commit 3c52c6bb831f6335c176a0fc7214e26f43adbd11
      category: bugfix
      bugzilla: 187825, https://gitee.com/src-openeuler/kernel/issues/I5VZ0J
      
      
      CVE: CVE-2022-3524
      
      --------------------------------
      
      syzbot reported a memory leak [0] related to IPV6_ADDRFORM.
      
      The scenario is that while one thread is converting an IPv6 socket into
      IPv4 with IPV6_ADDRFORM, another thread calls do_ipv6_setsockopt() and
      allocates memory to inet6_sk(sk)->XXX after conversion.
      
      Then, the converted sk with (tcp|udp)_prot never frees the IPv6 resources,
      which inet6_destroy_sock() should have cleaned up.
      
      setsockopt(IPV6_ADDRFORM)                 setsockopt(IPV6_DSTOPTS)
      +-----------------------+                 +----------------------+
      - do_ipv6_setsockopt(sk, ...)
        - sockopt_lock_sock(sk)                 - do_ipv6_setsockopt(sk, ...)
          - lock_sock(sk)                         ^._ called via tcpv6_prot
        - WRITE_ONCE(sk->sk_prot, &tcp_prot)          before WRITE_ONCE()
        - xchg(&np->opt, NULL)
        - txopt_put(opt)
        - sockopt_release_sock(sk)
          - release_sock(sk)                      - sockopt_lock_sock(sk)
                                                    - lock_sock(sk)
                                                  - ipv6_set_opt_hdr(sk, ...)
                                                    - ipv6_update_options(sk, opt)
                                                      - xchg(&inet6_sk(sk)->opt, opt)
                                                        ^._ opt is never freed.
      
                                                  - sockopt_release_sock(sk)
                                                    - release_sock(sk)
      
      Since IPV6_DSTOPTS allocates options under lock_sock(), we can avoid this
      memory leak by testing whether sk_family is changed by IPV6_ADDRFORM after
      acquiring the lock.
      
      This issue exists from the initial commit between IPV6_ADDRFORM and
      IPV6_PKTOPTIONS.
      
      [0]:
      BUG: memory leak
      unreferenced object 0xffff888009ab9f80 (size 96):
        comm "syz-executor583", pid 328, jiffies 4294916198 (age 13.034s)
        hex dump (first 32 bytes):
          01 00 00 00 48 00 00 00 08 00 00 00 00 00 00 00  ....H...........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000002ee98ae1>] kmalloc include/linux/slab.h:605 [inline]
          [<000000002ee98ae1>] sock_kmalloc+0xb3/0x100 net/core/sock.c:2566
          [<0000000065d7b698>] ipv6_renew_options+0x21e/0x10b0 net/ipv6/exthdrs.c:1318
          [<00000000a8c756d7>] ipv6_set_opt_hdr net/ipv6/ipv6_sockglue.c:354 [inline]
          [<00000000a8c756d7>] do_ipv6_setsockopt.constprop.0+0x28b7/0x4350 net/ipv6/ipv6_sockglue.c:668
          [<000000002854d204>] ipv6_setsockopt+0xdf/0x190 net/ipv6/ipv6_sockglue.c:1021
          [<00000000e69fdcf8>] tcp_setsockopt+0x13b/0x2620 net/ipv4/tcp.c:3789
          [<0000000090da4b9b>] __sys_setsockopt+0x239/0x620 net/socket.c:2252
          [<00000000b10d192f>] __do_sys_setsockopt net/socket.c:2263 [inline]
          [<00000000b10d192f>] __se_sys_setsockopt net/socket.c:2260 [inline]
          [<00000000b10d192f>] __x64_sys_setsockopt+0xbe/0x160 net/socket.c:2260
          [<000000000a80d7aa>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<000000000a80d7aa>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
          [<000000004562b5c6>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarXu Jia <xujia39@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Reviewed-by: default avatarLiu Jian <liujian56@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      0724868f
    • Russell King (Oracle)'s avatar
      net: mvpp2: fix mvpp2 debugfs leak · 92febc73
      Russell King (Oracle) authored
      mainline inclusion
      from mainline-v6.0-rc7
      commit 0152dfee235e87660f52a117fc9f70dc55956bb4
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7AX
      
      
      CVE: CVE-2022-3535
      
      --------------------------------
      
      When mvpp2 is unloaded, the driver specific debugfs directory is not
      removed, which technically leads to a memory leak. However, this
      directory is only created when the first device is probed, so the
      hardware is present. Removing the module is only something a developer
      would to when e.g. testing out changes, so the module would be
      reloaded. So this memory leak is minor.
      
      The original attempt in commit fe2c9c61f668 ("net: mvpp2: debugfs: fix
      memory leak when using debugfs_lookup()") that was labelled as a memory
      leak fix was not, it fixed a refcount leak, but in doing so created a
      problem when the module is reloaded - the directory already exists, but
      mvpp2_root is NULL, so we lose all debugfs entries. This fix has been
      reverted.
      
      This is the alternative fix, where we remove the offending directory
      whenever the driver is unloaded.
      
      Fixes: 21da57a2 ("net: mvpp2: add a debugfs interface for the Header Parser")
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Link: https://lore.kernel.org/r/E1ofOAB-00CzkG-UO@rmk-PC.armlinux.org.uk
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      
      Conflicts:
      	drivers/net/ethernet/marvell/mvpp2/mvpp2.h
      	drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
      Signed-off-by: default avatarHui Tang <tanghui20@huawei.com>
      Reviewed-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      92febc73
  8. Oct 19, 2022
  9. Oct 18, 2022
  10. Oct 17, 2022
    • Qian Cai's avatar
      mm/hotplug: silence a lockdep splat with printk() · 988dd3e9
      Qian Cai authored
      mainline inclusion
      from mainline-v5.6-rc1
      commit 4a55c0474a92d5c418bcbbe122368de0910aeac2q
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5T5DD
      CVE: NA
      
      --------------------------------
      
      It is not that hard to trigger lockdep splats by calling printk from
      under zone->lock.  Most of them are false positives caused by lock
      chains introduced early in the boot process and they do not cause any
      real problems (although most of the early boot lock dependencies could
      happen after boot as well).  There are some console drivers which do
      allocate from the printk context as well and those should be fixed.  In
      any case, false positives are not that trivial to workaround and it is
      far from optimal to lose lockdep functionality for something that is a
      non-issue.
      
      So change has_unmovable_pages() so that it no longer calls dump_page()
      itself - instead it returns a "struct page *" of the unmovable page back
      to the caller so that in the case of a has_unmovable_pages() failure,
      the caller can call dump_page() after releasing zone->lock.  Also, make
      dump_page() is able to report a CMA page as well, so the reason string
      from has_unmovable_pages() can be removed.
      
      Even though has_unmovable_pages doesn't hold any reference to the
      returned page this should be reasonably safe for the purpose of
      reporting the page (dump_page) because it cannot be hotremoved in the
      context of memory unplug.  The state of the page might change but that
      is the case even with the existing code as zone->lock only plays role
      for free pages.
      
      While at it, remove a similar but unnecessary debug-only printk() as
      well.  A sample of one of those lockdep splats is,
      
        WARNING: possible circular locking dependency detected
        ------------------------------------------------------
        test.sh/8653 is trying to acquire lock:
        ffffffff865a4460 (console_owner){-.-.}, at:
        console_unlock+0x207/0x750
      
        but task is already holding lock:
        ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at:
        __offline_isolated_pages+0x179/0x3e0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #3 (&(&zone->lock)->rlock){-.-.}:
               __lock_acquire+0x5b3/0xb40
               lock_acquire+0x126/0x280
               _raw_spin_lock+0x2f/0x40
               rmqueue_bulk.constprop.21+0xb6/0x1160
               get_page_from_freelist+0x898/0x22c0
               __alloc_pages_nodemask+0x2f3/0x1cd0
               alloc_pages_current+0x9c/0x110
               allocate_slab+0x4c6/0x19c0
               new_slab+0x46/0x70
               ___slab_alloc+0x58b/0x960
               __slab_alloc+0x43/0x70
               __kmalloc+0x3ad/0x4b0
               __tty_buffer_request_room+0x100/0x250
               tty_insert_flip_string_fixed_flag+0x67/0x110
               pty_write+0xa2/0xf0
               n_tty_write+0x36b/0x7b0
               tty_write+0x284/0x4c0
               __vfs_write+0x50/0xa0
               vfs_write+0x105/0x290
               redirected_tty_write+0x6a/0xc0
               do_iter_write+0x248/0x2a0
               vfs_writev+0x106/0x1e0
               do_writev+0xd4/0x180
               __x64_sys_writev+0x45/0x50
               do_syscall_64+0xcc/0x76c
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        -> #2 (&(&port->lock)->rlock){-.-.}:
               __lock_acquire+0x5b3/0xb40
               lock_acquire+0x126/0x280
               _raw_spin_lock_irqsave+0x3a/0x50
               tty_port_tty_get+0x20/0x60
               tty_port_default_wakeup+0xf/0x30
               tty_port_tty_wakeup+0x39/0x40
               uart_write_wakeup+0x2a/0x40
               serial8250_tx_chars+0x22e/0x440
               serial8250_handle_irq.part.8+0x14a/0x170
               serial8250_default_handle_irq+0x5c/0x90
               serial8250_interrupt+0xa6/0x130
               __handle_irq_event_percpu+0x78/0x4f0
               handle_irq_event_percpu+0x70/0x100
               handle_irq_event+0x5a/0x8b
               handle_edge_irq+0x117/0x370
               do_IRQ+0x9e/0x1e0
               ret_from_intr+0x0/0x2a
               cpuidle_enter_state+0x156/0x8e0
               cpuidle_enter+0x41/0x70
               call_cpuidle+0x5e/0x90
               do_idle+0x333/0x370
               cpu_startup_entry+0x1d/0x1f
               start_secondary+0x290/0x330
               secondary_startup_64+0xb6/0xc0
      
        -> #1 (&port_lock_key){-.-.}:
               __lock_acquire+0x5b3/0xb40
               lock_acquire+0x126/0x280
               _raw_spin_lock_irqsave+0x3a/0x50
               serial8250_console_write+0x3e4/0x450
               univ8250_console_write+0x4b/0x60
               console_unlock+0x501/0x750
               vprintk_emit+0x10d/0x340
               vprintk_default+0x1f/0x30
               vprintk_func+0x44/0xd4
               printk+0x9f/0xc5
      
        -> #0 (console_owner){-.-.}:
               check_prev_add+0x107/0xea0
               validate_chain+0x8fc/0x1200
               __lock_acquire+0x5b3/0xb40
               lock_acquire+0x126/0x280
               console_unlock+0x269/0x750
               vprintk_emit+0x10d/0x340
               vprintk_default+0x1f/0x30
               vprintk_func+0x44/0xd4
               printk+0x9f/0xc5
               __offline_isolated_pages.cold.52+0x2f/0x30a
               offline_isolated_pages_cb+0x17/0x30
               walk_system_ram_range+0xda/0x160
               __offline_pages+0x79c/0xa10
               offline_pages+0x11/0x20
               memory_subsys_offline+0x7e/0xc0
               device_offline+0xd5/0x110
               state_store+0xc6/0xe0
               dev_attr_store+0x3f/0x60
               sysfs_kf_write+0x89/0xb0
               kernfs_fop_write+0x188/0x240
               __vfs_write+0x50/0xa0
               vfs_write+0x105/0x290
               ksys_write+0xc6/0x160
               __x64_sys_write+0x43/0x50
               do_syscall_64+0xcc/0x76c
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        other info that might help us debug this:
      
        Chain exists of:
          console_owner --> &(&port->lock)->rlock --> &(&zone->lock)->rlock
      
         Possible unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(&(&zone->lock)->rlock);
                                       lock(&(&port->lock)->rlock);
                                       lock(&(&zone->lock)->rlock);
          lock(console_owner);
      
         *** DEADLOCK ***
      
        9 locks held by test.sh/8653:
         #0: ffff88839ba7d408 (sb_writers#4){.+.+}, at:
        vfs_write+0x25f/0x290
         #1: ffff888277618880 (&of->mutex){+.+.}, at:
        kernfs_fop_write+0x128/0x240
         #2: ffff8898131fc218 (kn->count#115){.+.+}, at:
        kernfs_fop_write+0x138/0x240
         #3: ffffffff86962a80 (device_hotplug_lock){+.+.}, at:
        lock_device_hotplug_sysfs+0x16/0x50
         #4: ffff8884374f4990 (&dev->mutex){....}, at:
        device_offline+0x70/0x110
         #5: ffffffff86515250 (cpu_hotplug_lock.rw_sem){++++}, at:
        __offline_pages+0xbf/0xa10
         #6: ffffffff867405f0 (mem_hotplug_lock.rw_sem){++++}, at:
        percpu_down_write+0x87/0x2f0
         #7: ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at:
        __offline_isolated_pages+0x179/0x3e0
         #8: ffffffff865a4920 (console_lock){+.+.}, at:
        vprintk_emit+0x100/0x340
      
        stack backtrace:
        Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10,
        BIOS U34 05/21/2019
        Call Trace:
         dump_stack+0x86/0xca
         print_circular_bug.cold.31+0x243/0x26e
         check_noncircular+0x29e/0x2e0
         check_prev_add+0x107/0xea0
         validate_chain+0x8fc/0x1200
         __lock_acquire+0x5b3/0xb40
         lock_acquire+0x126/0x280
         console_unlock+0x269/0x750
         vprintk_emit+0x10d/0x340
         vprintk_default+0x1f/0x30
         vprintk_func+0x44/0xd4
         printk+0x9f/0xc5
         __offline_isolated_pages.cold.52+0x2f/0x30a
         offline_isolated_pages_cb+0x17/0x30
         walk_system_ram_range+0xda/0x160
         __offline_pages+0x79c/0xa10
         offline_pages+0x11/0x20
         memory_subsys_offline+0x7e/0xc0
         device_offline+0xd5/0x110
         state_store+0xc6/0xe0
         dev_attr_store+0x3f/0x60
         sysfs_kf_write+0x89/0xb0
         kernfs_fop_write+0x188/0x240
         __vfs_write+0x50/0xa0
         vfs_write+0x105/0x290
         ksys_write+0xc6/0x160
         __x64_sys_write+0x43/0x50
         do_syscall_64+0xcc/0x76c
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Link: http://lkml.kernel.org/r/20200117181200.20299-1-cai@lca.pw
      
      
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Conflicts:
      	mm/debug.c
      	mm/page_alloc.
      	mm/page_isolation.c
      	mm/page-isolation.h
      Signed-off-by: default avatarMa Wupeng <mawupeng1@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      988dd3e9
    • Xia Fukun's avatar
      init/Kconfig: Add SMP to the dependencies of QOS_SCHED · 72b3422d
      Xia Fukun authored
      hulk inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5UPB0
      CVE: NA
      
      ------------------------------------------------------------
      
      After CONFIG_SMP is disabled during kernel compilation,
      CONFIG_QOS_SCHED is not disabled.
      As a result, the following error occurs:
      
      kernel/sched/fair.c: In function ‘check_qos_cfs_rq’:
      kernel/sched/fair.c:7324:4: error: implicit declaration of function
      ‘sched_idle_cpu’; did you mean ‘sched_idle_rq’?
      [-Werror=implicit-function-declaration]
       7324 |   !sched_idle_cpu(smp_processor_id()) &&
            |    ^~~~~~~~~~~~~~
      ./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
         78 | # define unlikely(x) __builtin_expect(!!(x), 0)
            |                                          ^
        CC      mm/highmem.o
      kernel/sched/fair.c: In function ‘pick_next_task_fair’:
      kernel/sched/fair.c:7599:43: error: ‘struct rq’ has no member named ‘online’
       7599 |   if (cfs_rq->...
      72b3422d
  11. Oct 14, 2022
    • Ma Wupeng's avatar
      mm/rmap: Fix kabi broken in anon_vma · 6d5d324d
      Ma Wupeng authored
      hulk inclusion
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP
      
      
      CVE: CVE-2022-42703
      
      --------------------------------
      
      In order to fix CVE-2022-42703, degree in struct anon_vma is splited into
      two variables(num_children, num_active_vmas) and this will lead to broken
      kabi.
      
      Since struct anon_vma is only used by mm module and referenced by other
      struct as pointers. So we can ignore this kabi change warning.
      
      For variable degree in struct anon_vma, previous patch has already
      delete this but this will lead to kabi change. Add it back at the same
      position. For variables(num_children, num_active_vmas), put them
      between macro __GENKSYMS__.
      
      Signed-off-by: default avatarMa Wupeng <mawupeng1@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      6d5d324d
    • Jann Horn's avatar
      mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse · a3544c89
      Jann Horn authored
      stable inclusion
      from stable-v4.19.257
      commit 6dbfc25d68d922736381988d64156a649ccf7bf1
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP
      
      
      CVE: CVE-2022-42703
      
      --------------------------------
      
      commit 2555283eb40df89945557273121e9393ef9b542b upstream.
      
      anon_vma->degree tracks the combined number of child anon_vmas and VMAs
      that use the anon_vma as their ->anon_vma.
      
      anon_vma_clone() then assumes that for any anon_vma attached to
      src->anon_vma_chain other than src->anon_vma, it is impossible for it to
      be a leaf node of the VMA tree, meaning that for such VMAs ->degree is
      elevated by 1 because of a child anon_vma, meaning that if ->degree
      equals 1 there are no VMAs that use the anon_vma as their ->anon_vma.
      
      This assumption is wrong because the ->degree optimization leads to leaf
      nodes being abandoned on anon_vma_clone() - an existing anon_vma is
      reused and no new parent-child relationship is created.  So it is
      possible to reuse an anon_vma for one VMA while it is still tied to
      another VMA.
      
      This is an issue because is_mergeable_anon_vma() and its callers assume
      that if two VMAs have the same ->anon_vma, the list of anon_vmas
      attached to the VMAs is guaranteed to be the same.  When this assumption
      is violated, vma_merge() can merge pages into a VMA that is not attached
      to the corresponding anon_vma, leading to dangling page->mapping
      pointers that will be dereferenced during rmap walks.
      
      Fix it by separately tracking the number of child anon_vmas and the
      number of VMAs using the anon_vma as their ->anon_vma.
      
      Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy")
      Cc: stable@kernel.org
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMa Wupeng <mawupeng1@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      a3544c89
    • Hyunwoo Kim's avatar
      HID: roccat: Fix use-after-free in roccat_read() · 4d870684
      Hyunwoo Kim authored
      mainline inclusion
      from mainline master
      commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5U1PE
      
      
      CVE: CVE-2022-41850
      
      --------------------------------
      
      roccat_report_event() is responsible for registering
      roccat-related reports in struct roccat_device.
      
      int roccat_report_event(int minor, u8 const *data)
      {
      	struct roccat_device *device;
      	struct roccat_reader *reader;
      	struct roccat_report *report;
      	uint8_t *new_value;
      
      	device = devices[minor];
      
      	new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
      	if (!new_value)
      		return -ENOMEM;
      
      	report = &device->cbuf[device->cbuf_end];
      
      	/* passing NULL is safe */
      	kfree(report->value);
      	...
      
      The registered report is stored in the struct roccat_device member
      "struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
      If more reports are received than the "ROCCAT_CBUF_SIZE" value,
      kfree() the saved report from cbuf[0] and allocates a new reprot.
      Since there is no lock when this kfree() is performed,
      kfree() can be performed even while reading the saved report.
      
      static ssize_t roccat_read(struct file *file, char __user *buffer,
      		size_t count, loff_t *ppos)
      {
      	struct roccat_reader *reader = file->private_data;
      	struct roccat_device *device = reader->device;
      	struct roccat_report *report;
      	ssize_t retval = 0, len;
      	DECLARE_WAITQUEUE(wait, current);
      
      	mutex_lock(&device->cbuf_lock);
      
      	...
      
      	report = &device->cbuf[reader->cbuf_start];
      	/*
      	 * If report is larger than requested amount of data, rest of report
      	 * is lost!
      	 */
      	len = device->report_size > count ? count : device->report_size;
      
      	if (copy_to_user(buffer, report->value, len)) {
      		retval = -EFAULT;
      		goto exit_unlock;
      	}
      	...
      
      The roccat_read() function receives the device->cbuf report and
      delivers it to the user through copy_to_user().
      If the N+ROCCAT_CBUF_SIZE th report is received while copying of
      the Nth report->value is in progress, the pointer that copy_to_user()
      is working on is kfree()ed and UAF read may occur. (race condition)
      
      Since the device node of this driver does not set separate permissions,
      this is not a security vulnerability, but because it is used for
      requesting screen display of profile or dpi settings,
      a user using the roccat device can apply udev to this device node or
      There is a possibility to use it by giving.
      
      Signed-off-by: default avatarHyunwoo Kim <imv4bel@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarCai Xinchen <caixinchen1@huawei.com>
      Reviewed-by: default avatarRuiqi Gong <gongruiqi1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      4d870684
  12. Oct 12, 2022