Skip to content
Snippets Groups Projects
  1. Feb 22, 2022
    • ChenXiaoSong's avatar
      configfs: fix a race in configfs_{,un}register_subsystem() · 84ec758f
      ChenXiaoSong authored
      
      When configfs_register_subsystem() or configfs_unregister_subsystem()
      is executing link_group() or unlink_group(),
      it is possible that two processes add or delete list concurrently.
      Some unfortunate interleavings of them can cause kernel panic.
      
      One of cases is:
      A --> B --> C --> D
      A <-- B <-- C <-- D
      
           delete list_head *B        |      delete list_head *C
      --------------------------------|-----------------------------------
      configfs_unregister_subsystem   |   configfs_unregister_subsystem
        unlink_group                  |     unlink_group
          unlink_obj                  |       unlink_obj
            list_del_init             |         list_del_init
              __list_del_entry        |           __list_del_entry
                __list_del            |             __list_del
                  // next == C        |
                  next->prev = prev   |
                                      |               next->prev = prev
                  prev->next = next   |
                                      |                 // prev == B
                                      |                 prev->next = next
      
      Fix this by adding mutex when calling link_group() or unlink_group(),
      but parent configfs_subsystem is NULL when config_item is root.
      So I create a mutex configfs_subsystem_mutex.
      
      Fixes: 7063fbf2 ("[PATCH] configfs: User-driven configuration filesystem")
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      84ec758f
  2. Jan 24, 2022
  3. Aug 25, 2021
  4. Aug 09, 2021
  5. Jul 13, 2021
    • Bart Van Assche's avatar
      configfs: fix the read and write iterators · 420405ec
      Bart Van Assche authored
      
      Commit 7fe1e79b ("configfs: implement the .read_iter and .write_iter
      methods") changed the simple_read_from_buffer() calls into copy_to_iter()
      calls and the simple_write_to_buffer() calls into copy_from_iter() calls.
      The simple*buffer() methods update the file offset (*ppos) but the read
      and write iterators not yet. Make the read and write iterators update the
      file offset (iocb->ki_pos).
      
      This patch has been tested as follows:
      
       # modprobe target_core_user
       # dd if=/sys/kernel/config/target/dbroot bs=1
      /var/target
      12+0 records in
      12+0 records out
      12 bytes copied, 9.5539e-05 s, 126 kB/s
      
       # cd /sys/kernel/config/acpi/table
       # mkdir test
       # cd test
       # dmesg -c >/dev/null; printf 'SSDT\x8\0\0\0abcdefghijklmnopqrstuvwxyz' | dd of=aml bs=1; dmesg -c
      34+0 records in
      34+0 records out
      34 bytes copied, 0.010627 s, 3.2 kB/s
      [  261.056551] ACPI configfs: invalid table length
      
      Reported-by: default avatarYanko Kaneti <yaneti@declera.com>
      Cc: Yanko Kaneti <yaneti@declera.com>
      Fixes: 7fe1e79b ("configfs: implement the .read_iter and .write_iter methods")
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      420405ec
  6. Jun 29, 2021
  7. Jun 22, 2021
  8. May 25, 2021
  9. May 07, 2021
  10. Mar 11, 2021
    • Daiyue Zhang's avatar
      configfs: fix a use-after-free in __configfs_open_file · 14fbbc82
      Daiyue Zhang authored
      
      Commit b0841eef ("configfs: provide exclusion between IO and removals")
      uses ->frag_dead to mark the fragment state, thus no bothering with extra
      refcount on config_item when opening a file. The configfs_get_config_item
      was removed in __configfs_open_file, but not with config_item_put. So the
      refcount on config_item will lost its balance, causing use-after-free
      issues in some occasions like this:
      
      Test:
      1. Mount configfs on /config with read-only items:
      drwxrwx--- 289 root   root            0 2021-04-01 11:55 /config
      drwxr-xr-x   2 root   root            0 2021-04-01 11:54 /config/a
      --w--w--w-   1 root   root         4096 2021-04-01 11:53 /config/a/1.txt
      ......
      
      2. Then run:
      for file in /config
      do
      echo $file
      grep -R 'key' $file
      done
      
      3. __configfs_open_file will be called in parallel, the first one
      got called will do:
      if (file->f_mode & FMODE_READ) {
      	if (!(inode->i_mode & S_IRUGO))
      		goto out_put_module;
      			config_item_put(buffer->item);
      				kref_put()
      					package_details_release()
      						kfree()
      
      the other one will run into use-after-free issues like this:
      BUG: KASAN: use-after-free in __configfs_open_file+0x1bc/0x3b0
      Read of size 8 at addr fffffff155f02480 by task grep/13096
      CPU: 0 PID: 13096 Comm: grep VIP: 00 Tainted: G        W       4.14.116-kasan #1
      TGID: 13096 Comm: grep
      Call trace:
      dump_stack+0x118/0x160
      kasan_report+0x22c/0x294
      __asan_load8+0x80/0x88
      __configfs_open_file+0x1bc/0x3b0
      configfs_open_file+0x28/0x34
      do_dentry_open+0x2cc/0x5c0
      vfs_open+0x80/0xe0
      path_openat+0xd8c/0x2988
      do_filp_open+0x1c4/0x2fc
      do_sys_open+0x23c/0x404
      SyS_openat+0x38/0x48
      
      Allocated by task 2138:
      kasan_kmalloc+0xe0/0x1ac
      kmem_cache_alloc_trace+0x334/0x394
      packages_make_item+0x4c/0x180
      configfs_mkdir+0x358/0x740
      vfs_mkdir2+0x1bc/0x2e8
      SyS_mkdirat+0x154/0x23c
      el0_svc_naked+0x34/0x38
      
      Freed by task 13096:
      kasan_slab_free+0xb8/0x194
      kfree+0x13c/0x910
      package_details_release+0x524/0x56c
      kref_put+0xc4/0x104
      config_item_put+0x24/0x34
      __configfs_open_file+0x35c/0x3b0
      configfs_open_file+0x28/0x34
      do_dentry_open+0x2cc/0x5c0
      vfs_open+0x80/0xe0
      path_openat+0xd8c/0x2988
      do_filp_open+0x1c4/0x2fc
      do_sys_open+0x23c/0x404
      SyS_openat+0x38/0x48
      el0_svc_naked+0x34/0x38
      
      To fix this issue, remove the config_item_put in
      __configfs_open_file to balance the refcount of config_item.
      
      Fixes: b0841eef ("configfs: provide exclusion between IO and removals")
      Signed-off-by: default avatarDaiyue Zhang <zhangdaiyue1@huawei.com>
      Signed-off-by: default avatarYi Chen <chenyi77@huawei.com>
      Signed-off-by: default avatarGe Qiu <qiuge@huawei.com>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      14fbbc82
  11. Jan 24, 2021
  12. Nov 14, 2020
  13. Oct 16, 2020
  14. Aug 23, 2020
  15. May 05, 2020
  16. Apr 27, 2020
    • Xiyu Yang's avatar
      configfs: fix config_item refcnt leak in configfs_rmdir() · 8aebfffa
      Xiyu Yang authored
      
      configfs_rmdir() invokes configfs_get_config_item(), which returns a
      reference of the specified config_item object to "parent_item" with
      increased refcnt.
      
      When configfs_rmdir() returns, local variable "parent_item" becomes
      invalid, so the refcount should be decreased to keep refcount balanced.
      
      The reference counting issue happens in one exception handling path of
      configfs_rmdir(). When down_write_killable() fails, the function forgets
      to decrease the refcnt increased by configfs_get_config_item(), causing
      a refcnt leak.
      
      Fix this issue by calling config_item_put() when down_write_killable()
      fails.
      
      Signed-off-by: default avatarXiyu Yang <xiyuyang19@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      8aebfffa
  17. Dec 09, 2019
  18. Nov 06, 2019
    • Honggang Li's avatar
      configfs: calculate the depth of parent item · e2f238f7
      Honggang Li authored
      
      When create symbolic link, create_link should calculate the depth
      of the parent item. However, both the first and second parameters
      of configfs_get_target_path had been set to the target. Broken
      symbolic link created.
      
      $ targetcli ls /
      o- / ............................................................. [...]
        o- backstores .................................................. [...]
        | o- block ...................................... [Storage Objects: 0]
        | o- fileio ..................................... [Storage Objects: 2]
        | | o- vdev0 .......... [/dev/ramdisk1 (16.0MiB) write-thru activated]
        | | | o- alua ....................................... [ALUA Groups: 1]
        | | |   o- default_tg_pt_gp ........... [ALUA state: Active/optimized]
        | | o- vdev1 .......... [/dev/ramdisk2 (16.0MiB) write-thru activated]
        | |   o- alua ....................................... [ALUA Groups: 1]
        | |     o- default_tg_pt_gp ........... [ALUA state: Active/optimized]
        | o- pscsi ...................................... [Storage Objects: 0]
        | o- ramdisk .................................... [Storage Objects: 0]
        o- iscsi ................................................ [Targets: 0]
        o- loopback ............................................. [Targets: 0]
        o- srpt ................................................. [Targets: 2]
        | o- ib.e89a8f91cb3200000000000000000000 ............... [no-gen-acls]
        | | o- acls ................................................ [ACLs: 2]
        | | | o- ib.e89a8f91cb3200000000000000000000 ........ [Mapped LUNs: 2]
        | | | | o- mapped_lun0 ............................. [BROKEN LUN LINK]
        | | | | o- mapped_lun1 ............................. [BROKEN LUN LINK]
        | | | o- ib.e89a8f91cb3300000000000000000000 ........ [Mapped LUNs: 2]
        | | |   o- mapped_lun0 ............................. [BROKEN LUN LINK]
        | | |   o- mapped_lun1 ............................. [BROKEN LUN LINK]
        | | o- luns ................................................ [LUNs: 2]
        | |   o- lun0 ...... [fileio/vdev0 (/dev/ramdisk1) (default_tg_pt_gp)]
        | |   o- lun1 ...... [fileio/vdev1 (/dev/ramdisk2) (default_tg_pt_gp)]
        | o- ib.e89a8f91cb3300000000000000000000 ............... [no-gen-acls]
        |   o- acls ................................................ [ACLs: 0]
        |   o- luns ................................................ [LUNs: 0]
        o- vhost ................................................ [Targets: 0]
      
      Fixes: e9c03af2 ("configfs: calculate the symlink target only once")
      Signed-off-by: default avatarHonggang Li <honli@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      e2f238f7
  19. Sep 11, 2019
  20. Sep 04, 2019
    • Al Viro's avatar
      configfs: provide exclusion between IO and removals · b0841eef
      Al Viro authored
      
      Make sure that attribute methods are not called after the item
      has been removed from the tree.  To do so, we
      	* at the point of no return in removals, grab ->frag_sem
      exclusive and mark the fragment dead.
      	* call the methods of attributes with ->frag_sem taken
      shared and only after having verified that the fragment is still
      alive.
      
      	The main benefit is for method instances - they are
      guaranteed that the objects they are accessing *and* all ancestors
      are still there.  Another win is that we don't need to bother
      with extra refcount on config_item when opening a file -
      the item will be alive for as long as it stays in the tree, and
      we won't touch it/attributes/any associated data after it's
      been removed from the tree.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      b0841eef
  21. Sep 02, 2019
  22. Aug 30, 2019
    • Deepa Dinamani's avatar
      timestamp_truncate: Replace users of timespec64_trunc · 3818c190
      Deepa Dinamani authored
      
      Update the inode timestamp updates to use timestamp_truncate()
      instead of timespec64_trunc().
      
      The change was mostly generated by the following coccinelle
      script.
      
      virtual context
      virtual patch
      
      @r1 depends on patch forall@
      struct inode *inode;
      identifier i_xtime =~ "^i_[acm]time$";
      expression e;
      @@
      
      inode->i_xtime =
      - timespec64_trunc(
      + timestamp_truncate(
      ...,
      - e);
      + inode);
      
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Cc: adrian.hunter@intel.com
      Cc: dedekind1@gmail.com
      Cc: gregkh@linuxfoundation.org
      Cc: hch@lst.de
      Cc: jaegeuk@kernel.org
      Cc: jlbec@evilplan.org
      Cc: richard@nod.at
      Cc: tj@kernel.org
      Cc: yuchao0@huawei.com
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: linux-mtd@lists.infradead.org
      3818c190
  23. Jul 05, 2019
  24. Jun 20, 2019
    • Amir Goldstein's avatar
      configfs: call fsnotify_rmdir() hook · 6146e78c
      Amir Goldstein authored and Jan Kara's avatar Jan Kara committed
      
      This will allow generating fsnotify delete events on unregister
      of group/subsystem after the fsnotify_nameremove() hook is removed
      from d_delete().
      
      The rest of the d_delete() calls from this filesystem are either
      called recursively from within debugfs_unregister_{group,subsystem},
      called from a vfs function that already has delete hooks or are
      called from shutdown/cleanup code.
      
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      6146e78c
  25. May 30, 2019
  26. May 28, 2019
  27. May 21, 2019
  28. May 08, 2019
    • YueHaibing's avatar
      configfs: fix possible use-after-free in configfs_register_group · 35399f87
      YueHaibing authored
      
      In configfs_register_group(), if create_default_group() failed, we
      forget to unlink the group. It will left a invalid item in the parent list,
      which may trigger the use-after-free issue seen below:
      
      BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
      Read of size 8 at addr ffff8881ef61ae20 by task syz-executor.0/5996
      
      CPU: 1 PID: 5996 Comm: syz-executor.0 Tainted: G         C        5.0.0+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xa9/0x10e lib/dump_stack.c:113
       print_address_description+0x65/0x270 mm/kasan/report.c:187
       kasan_report+0x149/0x18d mm/kasan/report.c:317
       __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
       __list_add include/linux/list.h:60 [inline]
       list_add_tail include/linux/list.h:93 [inline]
       link_obj+0xb0/0x190 fs/configfs/dir.c:759
       link_group+0x1c/0x130 fs/configfs/dir.c:784
       configfs_register_group+0x56/0x1e0 fs/configfs/dir.c:1751
       configfs_register_default_group+0x72/0xc0 fs/configfs/dir.c:1834
       ? 0xffffffffc1be0000
       iio_sw_trigger_init+0x23/0x1000 [industrialio_sw_trigger]
       do_one_initcall+0xbc/0x47d init/main.c:887
       do_init_module+0x1b5/0x547 kernel/module.c:3456
       load_module+0x6405/0x8c10 kernel/module.c:3804
       __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f494ecbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
      RBP: 00007f494ecbcc70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f494ecbd6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      
      Allocated by task 5987:
       set_track mm/kasan/common.c:87 [inline]
       __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497
       kmalloc include/linux/slab.h:545 [inline]
       kzalloc include/linux/slab.h:740 [inline]
       configfs_register_default_group+0x4c/0xc0 fs/configfs/dir.c:1829
       0xffffffffc1bd0023
       do_one_initcall+0xbc/0x47d init/main.c:887
       do_init_module+0x1b5/0x547 kernel/module.c:3456
       load_module+0x6405/0x8c10 kernel/module.c:3804
       __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 5987:
       set_track mm/kasan/common.c:87 [inline]
       __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459
       slab_free_hook mm/slub.c:1429 [inline]
       slab_free_freelist_hook mm/slub.c:1456 [inline]
       slab_free mm/slub.c:3003 [inline]
       kfree+0xe1/0x270 mm/slub.c:3955
       configfs_register_default_group+0x9a/0xc0 fs/configfs/dir.c:1836
       0xffffffffc1bd0023
       do_one_initcall+0xbc/0x47d init/main.c:887
       do_init_module+0x1b5/0x547 kernel/module.c:3456
       load_module+0x6405/0x8c10 kernel/module.c:3804
       __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881ef61ae00
       which belongs to the cache kmalloc-192 of size 192
      The buggy address is located 32 bytes inside of
       192-byte region [ffff8881ef61ae00, ffff8881ef61aec0)
      The buggy address belongs to the page:
      page:ffffea0007bd8680 count:1 mapcount:0 mapping:ffff8881f6c03000 index:0xffff8881ef61a700
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 ffffea0007ca4740 0000000500000005 ffff8881f6c03000
      raw: ffff8881ef61a700 000000008010000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881ef61ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff8881ef61ad80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      >ffff8881ef61ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                     ^
       ffff8881ef61ae80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff8881ef61af00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 5cf6a51e ("configfs: allow dynamic group creation")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      35399f87
Loading