Re: [PATCH] fs/9p: fix NULL pointer dereference on mkdir

[Dominique Martinet <asmadeus@codewreck.org>]

Christian Schoenebeck wrote on Thu, Mar 13, 2025 at 02:29:42PM +0100:
> On Thursday, March 13, 2025 1:59:32 PM CET Christian Schoenebeck wrote:
> > When a 9p tree was mounted with option 'posixacl', parent directory had a
> > default ACL set for its subdirectories, e.g.:
> > 
> >   setfacl -m default:group:simpsons:rwx parentdir
> > 
> > then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in
> > function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL
> > (since dafbe689736) even though the subsequent v9fs_set_create_acl() call
> > expects a valid non-NULL 'fid' pointer:
> > 
> >   [   37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000
> >   ...
> >   [   37.322338] Call Trace:
> >   [   37.323043]  <TASK>
> >   [   37.323621]  ? __die+0x1f/0x60
> >   [   37.324448]  ? page_fault_oops+0x158/0x470
> >   [   37.325532]  ? search_module_extables+0x4a/0x80
> >   [   37.326742]  ? p9_client_walk+0x1c/0x2c0 [9pnet]
> >   [   37.328006]  ? search_bpf_extables+0x5b/0x80
> >   [   37.329142]  ? exc_page_fault+0x72/0x190
> >   [   37.330196]  ? asm_exc_page_fault+0x22/0x30
> >   [   37.331330]  ? p9_client_walk+0x1c/0x2c0 [9pnet]
> >   [   37.332562]  ? v9fs_fid_xattr_get+0x59/0x120 [9p]
> >   [   37.333824]  v9fs_fid_xattr_set+0x6f/0x130 [9p]
> >   [   37.335077]  v9fs_set_acl+0x82/0xc0 [9p]
> >   [   37.336112]  v9fs_set_create_acl+0x41/0x60 [9p]
> >   [   37.337326]  v9fs_vfs_mkdir_dotl+0x20d/0x2e0 [9p]
> >   [   37.338590]  vfs_mkdir+0x192/0x250
> >   [   37.339535]  do_mkdirat+0x135/0x160
> >   [   37.340465]  __x64_sys_mkdir+0x42/0x60
> >   [   37.341455]  do_syscall_64+0x4b/0x110
> >   [   37.342447]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Oops, forgot to decode the trace back:
> 
> [   37.322338] Call Trace:
> [   37.323043]  <TASK>
> [   37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) 
> [   37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) 
> [   37.325532] ? search_module_extables (kernel/module/main.c:3733) 
> [   37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet 
> [   37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) 
> [   37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) 
> [   37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) 
> [   37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet 
> [   37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p 
> [   37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p 
> [   37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p 
> [   37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p 
> [   37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p 
> [   37.338590] vfs_mkdir (fs/namei.c:4313) 
> [   37.339535] do_mkdirat (fs/namei.c:4336) 
> [   37.340465] __x64_sys_mkdir (fs/namei.c:4354) 
> [   37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) 
> [   37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> 
> Dominique, do you want me to send a v2 or would you update the commit log on
> your end?

Thank you for the quick patch!
I can update the message on my end unless there's another reason to send
a v2

Looks good to me, I'll test a bit over the weekend and send to Linus in
the merge window in a couple of weeks (I guess it could be sent right
away...)
-- 
Dominique