Skip to content
Snippets Groups Projects
  1. Sep 30, 2022
  2. Sep 12, 2022
    • Hawkins Jiawei's avatar
      ntfs: check overflow when iterating ATTR_RECORDs · 63095f4f
      Hawkins Jiawei authored
      Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). 
      Because the ATTR_RECORDs are next to each other, kernel can get the next
      ATTR_RECORD from end address of current ATTR_RECORD, through current
      ATTR_RECORD length field.
      
      The problem is that during iteration, when kernel calculates the end
      address of current ATTR_RECORD, kernel may trigger an integer overflow bug
      in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`.  This
      may wrap, leading to a forever iteration on 32bit systems.
      
      This patch solves it by adding some checks on calculating end address
      of current ATTR_RECORD during iteration.
      
      Link: https://lkml.kernel.org/r/20220831160935.3409-4-yin31149@gmail.com
      Link: https://lore.kernel.org/all/20220827105842.GM2030@kadam/
      
      
      Signed-off-by: default avatarHawkins Jiawei <yin31149@gmail.com>
      Suggested-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: chenxiaosong (A) <chenxiaosong2@huawei.com>
      Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      63095f4f
    • Hawkins Jiawei's avatar
      ntfs: fix out-of-bounds read in ntfs_attr_find() · 36a4d82d
      Hawkins Jiawei authored
      Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find().  To
      ensure access on these ATTR_RECORDs are within bounds, kernel will do some
      checking during iteration.
      
      The problem is that during checking whether ATTR_RECORD's name is within
      bounds, kernel will dereferences the ATTR_RECORD name_offset field, before
      checking this ATTR_RECORD strcture is within bounds.  This problem may
      result out-of-bounds read in ntfs_attr_find(), reported by Syzkaller:
      
      ==================================================================
      BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
      Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607
      
      [...]
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description mm/kasan/report.c:317 [inline]
       print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
       kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
       ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
       ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193
       ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845
       ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854
       mount_bdev+0x34d/0x410 fs/super.c:1400
       legacy_get_tree+0x105/0x220 fs/fs_context.c:610
       vfs_get_tree+0x89/0x2f0 fs/super.c:1530
       do_new_mount fs/namespace.c:3040 [inline]
       path_mount+0x1326/0x1e20 fs/namespace.c:3370
       do_mount fs/namespace.c:3383 [inline]
       __do_sys_mount fs/namespace.c:3591 [inline]
       __se_sys_mount fs/namespace.c:3568 [inline]
       __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
       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+0x63/0xcd
       [...]
       </TASK>
      
      The buggy address belongs to the physical page:
      page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350
      head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0
      flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140
      raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      Memory state around the buggy address:
       ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
       ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      This patch solves it by moving the ATTR_RECORD strcture's bounds checking
      earlier, then checking whether ATTR_RECORD's name is within bounds. 
      What's more, this patch also add some comments to improve its
      maintainability.
      
      Link: https://lkml.kernel.org/r/20220831160935.3409-3-yin31149@gmail.com
      Link: https://lore.kernel.org/all/1636796c-c85e-7f47-e96f-e074fee3c7d3@huawei.com/
      Link: https://groups.google.com/g/syzkaller-bugs/c/t_XdeKPGTR4/m/LECAuIGcBgAJ
      
      
      Signed-off-by: default avatarchenxiaosong (A) <chenxiaosong2@huawei.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarHawkins Jiawei <yin31149@gmail.com>
      Reported-by: default avatar <syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com>
      Tested-by: default avatar <syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      36a4d82d
    • Hawkins Jiawei's avatar
      ntfs: fix use-after-free in ntfs_attr_find() · d85a1bec
      Hawkins Jiawei authored
      Patch series "ntfs: fix bugs about Attribute", v2.
      
      This patchset fixes three bugs relative to Attribute in record:
      
      Patch 1 adds a sanity check to ensure that, attrs_offset field in first
      mft record loading from disk is within bounds.
      
      Patch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid
      dereferencing ATTR_RECORD before checking this ATTR_RECORD is within
      bounds.
      
      Patch 3 adds an overflow checking to avoid possible forever loop in
      ntfs_attr_find().
      
      Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free
      detection as reported by Syzkaller.
      
      Although one of patch 1 or patch 2 can fix this, we still need both of
      them.  Because patch 1 fixes the root cause, and patch 2 not only fixes
      the direct cause, but also fixes the potential out-of-bounds bug.
      
      
      This patch (of 3):
      
      Syzkaller reported use-after-free read as follows:
      ==================================================================
      BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
      Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607
      
      [...]
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description mm/kasan/report.c:317 [inline]
       print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
       kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
       ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
       ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193
       ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845
       ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854
       mount_bdev+0x34d/0x410 fs/super.c:1400
       legacy_get_tree+0x105/0x220 fs/fs_context.c:610
       vfs_get_tree+0x89/0x2f0 fs/super.c:1530
       do_new_mount fs/namespace.c:3040 [inline]
       path_mount+0x1326/0x1e20 fs/namespace.c:3370
       do_mount fs/namespace.c:3383 [inline]
       __do_sys_mount fs/namespace.c:3591 [inline]
       __se_sys_mount fs/namespace.c:3568 [inline]
       __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
       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+0x63/0xcd
       [...]
       </TASK>
      
      The buggy address belongs to the physical page:
      page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350
      head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0
      flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140
      raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      Memory state around the buggy address:
       ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
       ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Kernel will loads $MFT/$DATA's first mft record in
      ntfs_read_inode_mount().
      
      Yet the problem is that after loading, kernel doesn't check whether
      attrs_offset field is a valid value.
      
      To be more specific, if attrs_offset field is larger than bytes_allocated
      field, then it may trigger the out-of-bounds read bug(reported as
      use-after-free bug) in ntfs_attr_find(), when kernel tries to access the
      corresponding mft record's attribute.
      
      This patch solves it by adding the sanity check between attrs_offset field
      and bytes_allocated field, after loading the first mft record.
      
      Link: https://lkml.kernel.org/r/20220831160935.3409-1-yin31149@gmail.com
      Link: https://lkml.kernel.org/r/20220831160935.3409-2-yin31149@gmail.com
      
      
      Signed-off-by: default avatarHawkins Jiawei <yin31149@gmail.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: ChenXiaoSong <chenxiaosong2@huawei.com>
      Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      d85a1bec
  3. Sep 11, 2022
    • ChenXiaoSong's avatar
      ntfs: fix BUG_ON in ntfs_lookup_inode_by_name() · 1b513f61
      ChenXiaoSong authored
      Syzkaller reported BUG_ON as follows:
      
      ------------[ cut here ]------------
      kernel BUG at fs/ntfs/dir.c:86!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
      CPU: 3 PID: 758 Comm: a.out Not tainted 5.19.0-next-20220808 #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      RIP: 0010:ntfs_lookup_inode_by_name+0xd11/0x2d10
      Code: ff e9 b9 01 00 00 e8 1e fe d6 fe 48 8b 7d 98 49 8d 5d 07 e8 91 85 29 ff 48 c7 45 98 00 00 00 00 e9 5a fb ff ff e8 ff fd d6 fe <0f> 0b e8 f8 fd d6 fe 0f 0b e8 f1 fd d6 fe 48 8b b5 50 ff ff ff 4c
      RSP: 0018:ffff888079607978 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000000
      RDX: ffff88807cf10000 RSI: ffffffff82a4a081 RDI: 0000000000000003
      RBP: ffff888079607a70 R08: 0000000000000001 R09: ffff88807a6d01d7
      R10: ffffed100f4da03a R11: 0000000000000000 R12: ffff88800f0fb110
      R13: ffff88800f0ee000 R14: ffff88800f0fb000 R15: 0000000000000001
      FS:  00007f33b63c7540(0000) GS:ffff888108580000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f33b635c090 CR3: 000000000f39e005 CR4: 0000000000770ee0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       <TASK>
       load_system_files+0x1f7f/0x3620
       ntfs_fill_super+0xa01/0x1be0
       mount_bdev+0x36a/0x440
       ntfs_mount+0x3a/0x50
       legacy_get_tree+0xfb/0x210
       vfs_get_tree+0x8f/0x2f0
       do_new_mount+0x30a/0x760
       path_mount+0x4de/0x1880
       __x64_sys_mount+0x2b3/0x340
       do_syscall_64+0x38/0x90
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7f33b62ff9ea
      Code: 48 8b 0d a9 f4 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 f4 0b 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffd0c471aa8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f33b62ff9ea
      RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd0c471be0
      RBP: 00007ffd0c471c60 R08: 00007ffd0c471ae0 R09: 00007ffd0c471c24
      R10: 0000000000000000 R11: 0000000000000202 R12: 000055bac5afc160
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       </TASK>
      Modules linked in:
      ---[ end trace 0000000000000000 ]---
      
      Fix this by adding sanity check on extended system files' directory inode
      to ensure that it is directory, just like ntfs_extend_init() when mounting
      ntfs3.
      
      Link: https://lkml.kernel.org/r/20220809064730.2316892-1-chenxiaosong2@huawei.com
      
      
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1b513f61
  4. Aug 02, 2022
  5. Jul 18, 2022
    • ChenXiaoSong's avatar
      ntfs: fix use-after-free in ntfs_ucsncmp() · 38c9c22a
      ChenXiaoSong authored
      Syzkaller reported use-after-free bug as follows:
      
      ==================================================================
      BUG: KASAN: use-after-free in ntfs_ucsncmp+0x123/0x130
      Read of size 2 at addr ffff8880751acee8 by task a.out/879
      
      CPU: 7 PID: 879 Comm: a.out Not tainted 5.19.0-rc4-next-20220630-00001-gcc5218c8bd2c-dirty #7
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x1c0/0x2b0
       print_address_description.constprop.0.cold+0xd4/0x484
       print_report.cold+0x55/0x232
       kasan_report+0xbf/0xf0
       ntfs_ucsncmp+0x123/0x130
       ntfs_are_names_equal.cold+0x2b/0x41
       ntfs_attr_find+0x43b/0xb90
       ntfs_attr_lookup+0x16d/0x1e0
       ntfs_read_locked_attr_inode+0x4aa/0x2360
       ntfs_attr_iget+0x1af/0x220
       ntfs_read_locked_inode+0x246c/0x5120
       ntfs_iget+0x132/0x180
       load_system_files+0x1cc6/0x3480
       ntfs_fill_super+0xa66/0x1cf0
       mount_bdev+0x38d/0x460
       legacy_get_tree+0x10d/0x220
       vfs_get_tree+0x93/0x300
       do_new_mount+0x2da/0x6d0
       path_mount+0x496/0x19d0
       __x64_sys_mount+0x284/0x300
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      RIP: 0033:0x7f3f2118d9ea
      Code: 48 8b 0d a9 f4 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 f4 0b 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffc269deac8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3f2118d9ea
      RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffc269dec00
      RBP: 00007ffc269dec80 R08: 00007ffc269deb00 R09: 00007ffc269dec44
      R10: 0000000000000000 R11: 0000000000000202 R12: 000055f81ab1d220
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       </TASK>
      
      The buggy address belongs to the physical page:
      page:0000000085430378 refcount:1 mapcount:1 mapping:0000000000000000 index:0x555c6a81d pfn:0x751ac
      memcg:ffff888101f7e180
      anon flags: 0xfffffc00a0014(uptodate|lru|mappedtodisk|swapbacked|node=0|zone=1|lastcpupid=0x1fffff)
      raw: 000fffffc00a0014 ffffea0001bf2988 ffffea0001de2448 ffff88801712e201
      raw: 0000000555c6a81d 0000000000000000 0000000100000000 ffff888101f7e180
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880751acd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff8880751ace00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff8880751ace80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                ^
       ffff8880751acf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff8880751acf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      
      The reason is that struct ATTR_RECORD->name_offset is 6485, end address of
      name string is out of bounds.
      
      Fix this by adding sanity check on end address of attribute name string.
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [chenxiaosong2@huawei.com: cleanup suggested by Hawkins Jiawei]
        Link: https://lkml.kernel.org/r/20220709064511.3304299-1-chenxiaosong2@huawei.com
      Link: https://lkml.kernel.org/r/20220707105329.4020708-1-chenxiaosong2@huawei.com
      
      
      Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
      Signed-off-by: default avatarHawkins Jiawei <yin31149@gmail.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: ChenXiaoSong <chenxiaosong2@huawei.com>
      Cc: Yongqiang Liu <liuyongqiang13@huawei.com>
      Cc: Zhang Yi <yi.zhang@huawei.com>
      Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      38c9c22a
  6. Jul 14, 2022
  7. Jun 29, 2022
  8. May 19, 2022
  9. May 09, 2022
  10. Apr 01, 2022
  11. Mar 22, 2022
  12. Mar 16, 2022
  13. Mar 15, 2022
  14. Jan 15, 2022
  15. Nov 27, 2021
    • Guenter Roeck's avatar
      fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k · 4eec7faf
      Guenter Roeck authored
      
      NTFS_RW code allocates page size dependent arrays on the stack. This
      results in build failures if the page size is 64k or larger.
      
        fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
        fs/ntfs/aops.c:1311:1: error:
      	the frame size of 2240 bytes is larger than 2048 bytes
      
      Since commit f22969a6 ("powerpc/64s: Default to 64K pages for 64 bit
      book3s") this affects ppc:allmodconfig builds, but other architectures
      supporting page sizes of 64k or larger are also affected.
      
      Increasing the maximum frame size for affected architectures just to
      silence this error does not really help.  The frame size would have to
      be set to a really large value for 256k pages.  Also, a large frame size
      could potentially result in stack overruns in this code and elsewhere
      and is therefore not desirable.  Make NTFS_RW dependent on page sizes
      smaller than 64k instead.
      
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4eec7faf
  16. Oct 18, 2021
  17. Jun 29, 2021
  18. Jun 10, 2021
  19. Jun 02, 2021
    • Al Viro's avatar
      ntfs_copy_from_user_iter(): don't bother with copying iov_iter · 90679312
      Al Viro authored
      
      Advance the original, let the caller revert if it needs to.
      Don't mess with iov_iter_single_seg_count() in the caller -
      if we got a (non-zero) short copy, use the amount actually
      copied for the next pass, limit it to "up to the end
      of page" if nothing got copied at all.
      
      Originally fault-in only read the first iovec; back then it used
      to make sense to limit to the just one iovec for the pass after
      short copy.  These days it's no long true.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      90679312
  20. Feb 24, 2021
  21. Jan 24, 2021
    • Christian Brauner's avatar
      fs: make helpers idmap mount aware · 549c7297
      Christian Brauner authored
      Extend some inode methods with an additional user namespace argument. A
      filesystem that is aware of idmapped mounts will receive the user
      namespace the mount has been marked with. This can be used for
      additional permission checking and also to enable filesystems to
      translate between uids and gids if they need to. We have implemented all
      relevant helpers in earlier patches.
      
      As requested we simply extend the exisiting inode method instead of
      introducing new ones. This is a little more code churn but it's mostly
      mechanical and doesnt't leave us with additional inode methods.
      
      Link: https://lore.kernel.org/r/20210121131959.646623-25-christian.brauner@ubuntu.com
      
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      549c7297
    • Christian Brauner's avatar
      attr: handle idmapped mounts · 2f221d6f
      Christian Brauner authored
      When file attributes are changed most filesystems rely on the
      setattr_prepare(), setattr_copy(), and notify_change() helpers for
      initialization and permission checking. Let them handle idmapped mounts.
      If the inode is accessed through an idmapped mount map it into the
      mount's user namespace. Afterwards the checks are identical to
      non-idmapped mounts. If the initial user namespace is passed nothing
      changes so non-idmapped mounts will see identical behavior as before.
      
      Helpers that perform checks on the ia_uid and ia_gid fields in struct
      iattr assume that ia_uid and ia_gid are intended values and have already
      been mapped correctly at the userspace-kernelspace boundary as we
      already do today. If the initial user namespace is passed nothing
      changes so non-idmapped mounts will see identical behavior as before.
      
      Link: https://lore.kernel.org/r/20210121131959.646623-8-christian.brauner@ubuntu.com
      
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      2f221d6f
  22. Dec 15, 2020
  23. Oct 14, 2020
  24. Sep 18, 2020
  25. Aug 07, 2020
  26. Jun 24, 2020
  27. Jun 02, 2020
  28. Apr 20, 2020
Loading