1. 23 May, 2024 1 commit
    • Dominique Martinet's avatar
      9p: add missing locking around taking dentry fid list · c898afdc
      Dominique Martinet authored
      Fix a use-after-free on dentry's d_fsdata fid list when a thread
      looks up a fid through dentry while another thread unlinks it:
      
      UAF thread:
      refcount_t: addition on 0; use-after-free.
       p9_fid_get linux/./include/net/9p/client.h:262
       v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129
       v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181
       v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314
       v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400
       vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
      
      Freed by:
       p9_fid_destroy (inlined)
       p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456
       p9_fid_put linux/./include/net/9p/client.h:278
       v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55
       v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518
       vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335
      
      The problem is that d_fsdata was not accessed under d_lock, because
      d_release() normally is only called once the dentry is otherwise no
      longer accessible but since we also call it explicitly in v9fs_remove
      that lock is required:
      move the hlist out of the dentry under lock then unref its fids once
      they are no longer accessible.
      
      Fixes: 154372e6 ("fs/9p: fix create-unlink-getattr idiom")
      Cc: stable@vger.kernel.org
      Reported-by: Meysam Firouzi
      Reported-by: Amirmohammad Eftekhar
      Reviewed-by: default avatarChristian Schoenebeck <linux_oss@crudebyte.com>
      Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org>
      Signed-off-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      c898afdc
  2. 21 May, 2024 1 commit
    • Nikita Zhandarovich's avatar
      net/9p: fix uninit-value in p9_client_rpc() · 25460d6f
      Nikita Zhandarovich authored
      Syzbot with the help of KMSAN reported the following error:
      
      BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
      BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
       trace_9p_client_res include/trace/events/9p.h:146 [inline]
       p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
       p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
       v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
       v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
       legacy_get_tree+0x114/0x290 fs/fs_context.c:662
       vfs_get_tree+0xa7/0x570 fs/super.c:1797
       do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
       path_mount+0x742/0x1f20 fs/namespace.c:3679
       do_mount fs/namespace.c:3692 [inline]
       __do_sys_mount fs/namespace.c:3898 [inline]
       __se_sys_mount+0x725/0x810 fs/namespace.c:3875
       __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
       do_syscall_64+0xd5/0x1f0
       entry_SYSCALL_64_after_hwframe+0x6d/0x75
      
      Uninit was created at:
       __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
       __alloc_pages_node include/linux/gfp.h:238 [inline]
       alloc_pages_node include/linux/gfp.h:261 [inline]
       alloc_slab_page mm/slub.c:2175 [inline]
       allocate_slab mm/slub.c:2338 [inline]
       new_slab+0x2de/0x1400 mm/slub.c:2391
       ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
       __slab_alloc mm/slub.c:3610 [inline]
       __slab_alloc_node mm/slub.c:3663 [inline]
       slab_alloc_node mm/slub.c:3835 [inline]
       kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
       p9_tag_alloc net/9p/client.c:278 [inline]
       p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
       p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
       p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
       v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
       v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
       legacy_get_tree+0x114/0x290 fs/fs_context.c:662
       vfs_get_tree+0xa7/0x570 fs/super.c:1797
       do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
       path_mount+0x742/0x1f20 fs/namespace.c:3679
       do_mount fs/namespace.c:3692 [inline]
       __do_sys_mount fs/namespace.c:3898 [inline]
       __se_sys_mount+0x725/0x810 fs/namespace.c:3875
       __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
       do_syscall_64+0xd5/0x1f0
       entry_SYSCALL_64_after_hwframe+0x6d/0x75
      
      If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
      will not be properly initialized. However, trace_9p_client_res()
      ends up trying to print it out anyway before p9_client_rpc()
      finishes.
      
      Fix this issue by assigning default values to p9_fcall fields
      such as 'tag' and (just in case KMSAN unearths something new) 'id'
      during the tag allocation stage.
      
      Reported-and-tested-by: syzbot+ff14db38f56329ef68df@syzkaller.appspotmail.com
      Fixes: 348b5901 ("net/9p: Convert net/9p protocol dumps to tracepoints")
      Signed-off-by: default avatarNikita Zhandarovich <n.zhandarovich@fintech.ru>
      Reviewed-by: default avatarChristian Schoenebeck <linux_oss@crudebyte.com>
      Cc: stable@vger.kernel.org
      Message-ID: <20240408141039.30428-1-n.zhandarovich@fintech.ru>
      Signed-off-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      25460d6f
  3. 12 May, 2024 5 commits
  4. 11 May, 2024 10 commits
  5. 10 May, 2024 20 commits
  6. 09 May, 2024 3 commits