Skip to content
Snippets Groups Projects
  1. May 23, 2022
    • Zhang Qiao's avatar
      sched/qos: Remove dependency CONFIG_x86 · 045a6974
      Zhang Qiao authored
      hulk inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZJT
      
      
      CVE: NA
      
      --------------------------------
      
      After removing dependency CONFIG_x86, if enable CONFIG_QOS_SCHED,
      only x86 server can handle priority inversion issue.
      
      Signed-off-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Reviewed-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      Reviewed-by: default avatarChen Hui <judy.chenhui@huawei.com>
      Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
      Reviewed-by: default avatarChen Hui <judy.chenhui@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      045a6974
    • Eric Dumazet's avatar
      net/sched: cls_u32: fix netns refcount changes in u32_change() · bede0bb3
      Eric Dumazet authored
      stable inclusion
      from stable-v4.19.241
      commit 75b0cc7904da7b40c6e8f2cf3ec4223b292b1184
      category: bugfix
      bugzilla: 186701, https://gitee.com/src-openeuler/kernel/issues/I5850T
      
      
      CVE: CVE-2022-29581
      
      --------------------------------
      
      commit 3db09e762dc79584a69c10d74a6b98f89a9979f8 upstream.
      
      We are now able to detect extra put_net() at the moment
      they happen, instead of much later in correct code paths.
      
      u32_init_knode() / tcf_exts_init() populates the ->exts.net
      pointer, but as mentioned in tcf_exts_init(),
      the refcount on netns has not been elevated yet.
      
      The refcount is taken only once tcf_exts_get_net()
      is called.
      
      So the two u32_destroy_key() calls from u32_change()
      are attempting to release an invalid reference on the netns.
      
      syzbot report:
      
      refcount_t: decrement hit 0; leaking memory.
      WARNING: CPU: 0 PID: 21708 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Modules linked in:
      CPU: 0 PID: 21708 Comm: syz-executor.5 Not tainted 5.18.0-rc2-next-20220412-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Code: 1d 14 b6 b2 09 31 ff 89 de e8 6d e9 89 fd 84 db 75 e0 e8 84 e5 89 fd 48 c7 c7 40 aa 26 8a c6 05 f4 b5 b2 09 01 e8 e5 81 2e 05 <0f> 0b eb c4 e8 68 e5 89 fd 0f b6 1d e3 b5 b2 09 31 ff 89 de e8 38
      RSP: 0018:ffffc900051af1b0 EFLAGS: 00010286
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000040000 RSI: ffffffff8160a0c8 RDI: fffff52000a35e28
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffffff81604a9e R11: 0000000000000000 R12: 1ffff92000a35e3b
      R13: 00000000ffffffef R14: ffff8880211a0194 R15: ffff8880577d0a00
      FS:  00007f25d183e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f19c859c028 CR3: 0000000051009000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       __refcount_dec include/linux/refcount.h:344 [inline]
       refcount_dec include/linux/refcount.h:359 [inline]
       ref_tracker_free+0x535/0x6b0 lib/ref_tracker.c:118
       netns_tracker_free include/net/net_namespace.h:327 [inline]
       put_net_track include/net/net_namespace.h:341 [inline]
       tcf_exts_put_net include/net/pkt_cls.h:255 [inline]
       u32_destroy_key.isra.0+0xa7/0x2b0 net/sched/cls_u32.c:394
       u32_change+0xe01/0x3140 net/sched/cls_u32.c:909
       tc_new_tfilter+0x98d/0x2200 net/sched/cls_api.c:2148
       rtnetlink_rcv_msg+0x80d/0xb80 net/core/rtnetlink.c:6016
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2495
       netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
       netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
       netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
       sock_sendmsg_nosec net/socket.c:705 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:725
       ____sys_sendmsg+0x6e2/0x800 net/socket.c:2413
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
       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+0x44/0xae
      RIP: 0033:0x7f25d0689049
      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:00007f25d183e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f25d079c030 RCX: 00007f25d0689049
      RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000005
      RBP: 00007f25d06e308d R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffd0b752e3f R14: 00007f25d183e300 R15: 0000000000022000
       </TASK>
      
      Fixes: 35c55fc1 ("cls_u32: use tcf_exts_get_net() before call_rcu()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.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>
      [rkolchmeyer: Backported to 4.19: adjusted u32_destroy_key() signature]
      Signed-off-by: default avatarRobert Kolchmeyer <rkolchmeyer@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarXu Jia <xujia39@huawei.com>
      Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      bede0bb3
    • Liu Shixin's avatar
      mm: hwpoison: enable memory error handling on 1GB hugepage optionaly · 2299190c
      Liu Shixin authored
      hulk inclusion
      category: feature
      bugzilla: 186704, https://gitee.com/openeuler/kernel/issues/I574NB
      
      
      CVE: NA
      
      --------------------------------
      
      The memory error handling on 1GB hugepage is disabled by commit 31286a84
      because it may lead to a kernel panic.
      
      However, the commit will result a more troublesome downstream problem. So we
      have to revert it in some situation. At the same time, we backport commit
      15494520 which resolve the kernel panic described in commit 31286a84.
      
      We add a new cmdline named 'hugetlb_hwpoison_full' to enable memory error
      handling on 1GB hugepage. By default, the memory error handling on 1GB hugepage
      is disabled.
      
      Note that the kernel panic may not have been completely resolved!
      
      Signed-off-by: default avatarLiu Shixin <liushixin2@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      2299190c
    • Qiujun Huang's avatar
      mm: fix gup_pud_range · 5a13dee5
      Qiujun Huang authored
      mainline inclusion
      from mainline-v5.6-rc1
      commit 15494520
      category: bugfix
      bugzilla: 186704, https://gitee.com/openeuler/kernel/issues/I574NB
      CVE: NA
      
      --------------------------------
      
      sorry for not processing for a long time.  I met it again.
      
      patch v1   https://lkml.org/lkml/2019/9/20/656
      
      do_machine_check()
        do_memory_failure()
          memory_failure()
            hw_poison_user_mappings()
              try_to_unmap()
                pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));
      
      ...and now we have a swap entry that indicates that the page entry
      refers to a bad (and poisoned) page of memory, but gup_fast() at this
      level of the page table was ignoring swap entries, and incorrectly
      assuming that "!pxd_none() == valid and present".
      
      And this was not just a poisoned page problem, but a generaly swap entry
      problem.  So, any swap entry type (device memory migration, numa
      migration, or just regular swapping) could lead to the same problem.
      
      Fix this by checking for pxd_present(), instead of pxd_none().
      
      Link: http://lkml.kernel.org/r/1578479084-15508-1-git-send-email-hqjagain@gmail.com
      
      
      Signed-off-by: default avatarQiujun Huang <hqjagain@gmail.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLiu Shixin <liushixin2@huawei.com>
      Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      5a13dee5
    • Duoming Zhou's avatar
      nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs · 08f5d6a4
      Duoming Zhou authored
      stable inclusion
      from stable-v4.19.242
      commit b266f492b2af82269aaaab871ac3949420ae678c
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I584YD
      
      
      CVE: CVE-2022-1734
      
      --------------------------------
      
      commit d270453a0d9ec10bb8a802a142fb1b3601a83098 upstream.
      
      There are destructive operations such as nfcmrvl_fw_dnld_abort and
      gpio_free in nfcmrvl_nci_unregister_dev. The resources such as firmware,
      gpio and so on could be destructed while the upper layer functions such as
      nfcmrvl_fw_dnld_start and nfcmrvl_nci_recv_frame is executing, which leads
      to double-free, use-after-free and null-ptr-deref bugs.
      
      There are three situations that could lead to double-free bugs.
      
      The first situation is shown below:
      
         (Thread 1)                 |      (Thread 2)
      nfcmrvl_fw_dnld_start         |
       ...                          |  nfcmrvl_nci_unregister_dev
       release_firmware()           |   nfcmrvl_fw_dnld_abort
        kfree(fw) //(1)             |    fw_dnld_over
                                    |     release_firmware
        ...                         |      kfree(fw) //(2)
                                    |     ...
      
      The second situation is shown below:
      
         (Thread 1)                 |      (Thread 2)
      nfcmrvl_fw_dnld_start         |
       ...                          |
       mod_timer                    |
       (wait a time)                |
       fw_dnld_timeout              |  nfcmrvl_nci_unregister_dev
         fw_dnld_over               |   nfcmrvl_fw_dnld_abort
          release_firmware          |    fw_dnld_over
           kfree(fw) //(1)          |     release_firmware
           ...                      |      kfree(fw) //(2)
      
      The third situation is shown below:
      
             (Thread 1)               |       (Thread 2)
      nfcmrvl_nci_recv_frame          |
       if(..->fw_download_in_progress)|
        nfcmrvl_fw_dnld_recv_frame    |
         queue_work                   |
                                      |
      fw_dnld_rx_work                 | nfcmrvl_nci_unregister_dev
       fw_dnld_over                   |  nfcmrvl_fw_dnld_abort
        release_firmware              |   fw_dnld_over
         kfree(fw) //(1)              |    release_firmware
                                      |     kfree(fw) //(2)
      
      The firmware struct is deallocated in position (1) and deallocated
      in position (2) again.
      
      The crash trace triggered by POC is like below:
      
      BUG: KASAN: double-free or invalid-free in fw_dnld_over
      Call Trace:
        kfree
        fw_dnld_over
        nfcmrvl_nci_unregister_dev
        nci_uart_tty_close
        tty_ldisc_kill
        tty_ldisc_hangup
        __tty_hangup.part.0
        tty_release
        ...
      
      What's more, there are also use-after-free and null-ptr-deref bugs
      in nfcmrvl_fw_dnld_start. If we deallocate firmware struct, gpio or
      set null to the members of priv->fw_dnld in nfcmrvl_nci_unregister_dev,
      then, we dereference firmware, gpio or the members of priv->fw_dnld in
      nfcmrvl_fw_dnld_start, the UAF or NPD bugs will happen.
      
      This patch reorders destructive operations after nci_unregister_device
      in order to synchronize between cleanup routine and firmware download
      routine.
      
      The nci_unregister_device is well synchronized. If the device is
      detaching, the firmware download routine will goto error. If firmware
      download routine is executing, nci_unregister_device will wait until
      firmware download routine is finished.
      
      v1->v2 change:
       	- fix stable branch
      
      Fixes: 3194c687 ("NFC: nfcmrvl: add firmware download support")
      Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBaisong Zhong <zhongbaisong@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      08f5d6a4
    • Zhang Yi's avatar
      ext4: fix warning when submitting superblock in ext4_commit_super() · ac5df7ff
      Zhang Yi authored
      hulk inclusion
      category: bugfix
      bugzilla: 186737, https://gitee.com/openeuler/kernel/issues/I58COJ
      
      
      CVE: NA
      
      --------------------------------
      
      We have already check the io_error and uptodate flag before submitting
      the superblock buffer, and re-set the uptodate flag if it has been
      failed to write out. But it was lockless and could be raced by another
      ext4_commit_super(), and finally trigger '!uptodate' WARNING when
      marking buffer dirty. Fix it by submit buffer directly.
      
      Signed-off-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      ac5df7ff
  2. May 19, 2022
    • Baokun Li's avatar
      ext4: fix bug_on in __es_tree_search · fec5e578
      Baokun Li authored
      hulk inclusion
      category: bugfix
      bugzilla: 186770, https://gitee.com/openeuler/kernel/issues/I58670
      
      
      CVE: NA
      
      --------------------------------
      
      Hulk Robot reported a BUG_ON:
      
      ==================================================================
      kernel BUG at fs/ext4/extents_status.c:199!
      [...]
      RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline]
      RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217
      [...]
      Call Trace:
       ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766
       ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561
       ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964
       ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384
       ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567
       ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980
       ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031
       ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257
       v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63
       v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82
       vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368
       dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490
       ext4_quota_enable fs/ext4/super.c:6137 [inline]
       ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163
       ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754
       mount_bdev+0x2e9/0x3b0 fs/super.c:1158
       mount_fs+0x4b/0x1e4 fs/super.c:1261
      [...]
      ==================================================================
      
      Above issue may happen as follows:
      -------------------------------------
      ext4_fill_super
       ext4_enable_quotas
        ext4_quota_enable
         ext4_iget
          __ext4_iget
           ext4_ext_check_inode
            ext4_ext_check
             __ext4_ext_check
              ext4_valid_extent_entries
               Check for overlapping extents does't take effect
         dquot_enable
          vfs_load_quota_inode
           v2_check_quota_file
            v2_read_header
             ext4_quota_read
              ext4_bread
               ext4_getblk
                ext4_map_blocks
                 ext4_ext_map_blocks
                  ext4_find_extent
                   ext4_cache_extents
                    ext4_es_cache_extent
                     ext4_es_cache_extent
                      __es_tree_search
                       ext4_es_end
                        BUG_ON(es->es_lblk + es->es_len < es->es_lblk)
      
      The error ext4 extents is as follows:
      0af3 0300 0400 0000 00000000    extent_header
      00000000 0100 0000 12000000     extent1
      00000000 0100 0000 18000000     extent2
      02000000 0400 0000 14000000     extent3
      
      In the ext4_valid_extent_entries function,
      if prev is 0, no error is returned even if lblock<=prev.
      This was intended to skip the check on the first extent, but
      in the error image above, prev=0+1-1=0 when checking the second extent,
      so even though lblock<=prev, the function does not return an error.
      As a result, bug_ON occurs in __es_tree_search and the system panics.
      
      To solve this problem, we only need to check that:
      1. The lblock of the first extent is not less than 0.
      2. The lblock of the next extent  is not less than
         the next block of the previous extent.
      The same applies to extent_idx.
      
      Fixes: 5946d089 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarBaokun Li <libaokun1@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      fec5e578
  3. May 18, 2022
  4. May 17, 2022
  5. May 13, 2022
  6. May 12, 2022
    • Ye Bin's avatar
      ext4: fix bug_on in start_this_handle during umount filesystem · 84597fe1
      Ye Bin authored
      mainline inclusion
      from mainline-v5.18-rc4
      commit b98535d091795a79336f520b0708457aacf55c67
      category: bugfix
      bugzilla: 186675, https://gitee.com/openeuler/kernel/issues/I55TUC
      
      
      CVE: NA
      
      -------------------------------------------------
      
      We got issue as follows:
      ------------[ cut here ]------------
      kernel BUG at fs/jbd2/transaction.c:389!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
      CPU: 9 PID: 131 Comm: kworker/9:1 Not tainted 5.17.0-862.14.0.6.x86_64-00001-g23f87daf7d74-dirty #197
      Workqueue: events flush_stashed_error_work
      RIP: 0010:start_this_handle+0x41c/0x1160
      RSP: 0018:ffff888106b47c20 EFLAGS: 00010202
      RAX: ffffed10251b8400 RBX: ffff888128dc204c RCX: ffffffffb52972ac
      RDX: 0000000000000200 RSI: 0000000000000004 RDI: ffff888128dc2050
      RBP: 0000000000000039 R08: 0000000000000001 R09: ffffed10251b840a
      R10: ffff888128dc204f R11: ffffed10251b8409 R12: ffff888116d78000
      R13: 0000000000000000 R14: dffffc0000000000 R15: ffff888128dc2000
      FS:  0000000000000000(0000) GS:ffff88839d680000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000001620068 CR3: 0000000376c0e000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       jbd2__journal_start+0x38a/0x790
       jbd2_journal_start+0x19/0x20
       flush_stashed_error_work+0x110/0x2b3
       process_one_work+0x688/0x1080
       worker_thread+0x8b/0xc50
       kthread+0x26f/0x310
       ret_from_fork+0x22/0x30
       </TASK>
      Modules linked in:
      ---[ end trace 0000000000000000 ]---
      
      Above issue may happen as follows:
            umount            read procfs            error_work
      ext4_put_super
        flush_work(&sbi->s_error_work);
      
                            ext4_mb_seq_groups_show
      	                ext4_mb_load_buddy_gfp
      			  ext4_mb_init_group
      			    ext4_mb_init_cache
      	                      ext4_read_block_bitmap_nowait
      			        ext4_validate_block_bitmap
      				  ext4_error
      			            ext4_handle_error
      			              schedule_work(&EXT4_SB(sb)->s_error_work);
      
        ext4_unregister_sysfs(sb);
        jbd2_journal_destroy(sbi->s_journal);
          journal_kill_thread
            journal->j_flags |= JBD2_UNMOUNT;
      
                                                flush_stashed_error_work
      				            jbd2_journal_start
      					      start_this_handle
      					        BUG_ON(journal->j_flags & JBD2_UNMOUNT);
      
      To solve this issue, we call 'ext4_unregister_sysfs() before flushing
      s_error_work in ext4_put_super().
      
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Link: https://lore.kernel.org/r/20220322012419.725457-1-yebin10@huawei.com
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      
      conflicts:
      	fs/ext4/super.c
      
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Reviewed-by: default avataryebin <yebin10@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      84597fe1
    • Ritesh Harjani's avatar
      ext4: unregister sysfs path before destroying jbd2 journal · e2aee868
      Ritesh Harjani authored
      mainline inclusion
      from mainline-v5.7-rc1
      commit 5e47868f
      category: bugfix
      bugzilla: 186675, https://gitee.com/openeuler/kernel/issues/I55TUC
      
      
      CVE: NA
      
      -------------------------------------------------
      
      Call ext4_unregister_sysfs(), before destroying jbd2 journal,
      since below might cause, NULL pointer dereference issue.
      This got reported with LTP tests.
      
      ext4_put_super() 		cat /sys/fs/ext4/loop2/journal_task
      	| 				ext4_attr_show();
      ext4_jbd2_journal_destroy();  			|
          	|				 journal_task_show()
      	| 					|
      	| 				task_pid_vnr(NULL);
      sbi->s_journal = NULL;
      
      Signed-off-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20200318061301.4320-1-riteshh@linux.ibm.com
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      
      conflicts:
      	fs/ext4/super.c
      
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Reviewed-by: default avataryebin <yebin10@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      e2aee868
    • Ye Bin's avatar
      ext4: fix use-after-free in ext4_search_dir · 0ddc1e48
      Ye Bin authored
      mainline inclusion
      from mainline-v5.18-rc4
      commit c186f0887fe7061a35cebef024550ec33ef8fbd8
      category: bugfix
      bugzilla: 186477, https://gitee.com/openeuler/kernel/issues/I55UHT
      
      
      CVE: NA
      
      -------------------------------------------------
      
      We got issue as follows:
      EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue
      
      ==================================================================
      BUG: KASAN: use-after-free in ext4_search_dir fs/ext4/namei.c:1394 [inline]
      BUG: KASAN: use-after-free in search_dirblock fs/ext4/namei.c:1199 [inline]
      BUG: KASAN: use-after-free in __ext4_find_entry+0xdca/0x1210 fs/ext4/namei.c:1553
      Read of size 1 at addr ffff8881317c3005 by task syz-executor117/2331
      
      CPU: 1 PID: 2331 Comm: syz-executor117 Not tainted 5.10.0+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:83 [inline]
       dump_stack+0x144/0x187 lib/dump_stack.c:124
       print_address_description+0x7d/0x630 mm/kasan/report.c:387
       __kasan_report+0x132/0x190 mm/kasan/report.c:547
       kasan_report+0x47/0x60 mm/kasan/report.c:564
       ext4_search_dir fs/ext4/namei.c:1394 [inline]
       search_dirblock fs/ext4/namei.c:1199 [inline]
       __ext4_find_entry+0xdca/0x1210 fs/ext4/namei.c:1553
       ext4_lookup_entry fs/ext4/namei.c:1622 [inline]
       ext4_lookup+0xb8/0x3a0 fs/ext4/namei.c:1690
       __lookup_hash+0xc5/0x190 fs/namei.c:1451
       do_rmdir+0x19e/0x310 fs/namei.c:3760
       do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x445e59
      Code: 4d c7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 1b c7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fff2277fac8 EFLAGS: 00000246 ORIG_RAX: 0000000000000054
      RAX: ffffffffffffffda RBX: 0000000000400280 RCX: 0000000000445e59
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000002
      R10: 00007fff2277f990 R11: 0000000000000246 R12: 0000000000000000
      R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
      
      The buggy address belongs to the page:
      page:0000000048cd3304 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1317c3
      flags: 0x200000000000000()
      raw: 0200000000000000 ffffea0004526588 ffffea0004528088 0000000000000000
      raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881317c2f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff8881317c2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff8881317c3000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                         ^
       ffff8881317c3080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff8881317c3100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      ==================================================================
      
      ext4_search_dir:
        ...
        de = (struct ext4_dir_entry_2 *)search_buf;
        dlimit = search_buf + buf_size;
        while ((char *) de < dlimit) {
        ...
          if ((char *) de + de->name_len <= dlimit &&
      	 ext4_match(dir, fname, de)) {
      	    ...
          }
        ...
          de_len = ext4_rec_len_from_disk(de->rec_len, dir->i_sb->s_blocksize);
          if (de_len <= 0)
            return -1;
          offset += de_len;
          de = (struct ext4_dir_entry_2 *) ((char *) de + de_len);
        }
      
      Assume:
      de=0xffff8881317c2fff
      dlimit=0x0xffff8881317c3000
      
      If read 'de->name_len' which address is 0xffff8881317c3005, obviously is
      out of range, then will trigger use-after-free.
      To solve this issue, 'dlimit' must reserve 8 bytes, as we will read
      'de->name_len' to judge if '(char *) de + de->name_len' out of range.
      
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20220324064816.1209985-1-yebin10@huawei.com
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      
      conflicts:
      	fs/ext4/namei.c
      
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Reviewed-by: default avatarZhang Yi <yi.zhang@huawei.com>
      Reviewed-by: default avataryebin <yebin10@huawei.com>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      0ddc1e48
  7. May 09, 2022
  8. May 07, 2022