* [PATCH] fs/9p: fix NULL pointer dereference on mkdir
@ 2025-03-13 12:59 Christian Schoenebeck
2025-03-13 13:29 ` Christian Schoenebeck
0 siblings, 1 reply; 3+ messages in thread
From: Christian Schoenebeck @ 2025-03-13 12:59 UTC (permalink / raw)
To: Dominique Martinet
Cc: Eric Van Hensbergen, Latchesar Ionkov, v9fs, linux-kernel, syzbot
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
Fix this by simply swapping the sequence of these two calls in
v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before
v9fs_fid_add().
Fixes: dafbe689736 ('9p fid refcount: cleanup p9_fid_put calls')
Reported-by: syzbot+5b667f9a1fee4ba3775a@syzkaller.appspotmail.com
Signed-off-by: Christian Schoenebeck <linux_oss@crudebyte.com>
---
fs/9p/vfs_inode_dotl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index 143ac03b7425..3397939fd2d5 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -407,8 +407,8 @@ static int v9fs_vfs_mkdir_dotl(struct mnt_idmap *idmap,
err);
goto error;
}
- v9fs_fid_add(dentry, &fid);
v9fs_set_create_acl(inode, fid, dacl, pacl);
+ v9fs_fid_add(dentry, &fid);
d_instantiate(dentry, inode);
err = 0;
inc_nlink(dir);
--
2.39.5
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] fs/9p: fix NULL pointer dereference on mkdir
2025-03-13 12:59 [PATCH] fs/9p: fix NULL pointer dereference on mkdir Christian Schoenebeck
@ 2025-03-13 13:29 ` Christian Schoenebeck
2025-03-13 13:33 ` Dominique Martinet
0 siblings, 1 reply; 3+ messages in thread
From: Christian Schoenebeck @ 2025-03-13 13:29 UTC (permalink / raw)
To: Dominique Martinet
Cc: Eric Van Hensbergen, Latchesar Ionkov, v9fs, linux-kernel, syzbot
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?
/Christian
> Fix this by simply swapping the sequence of these two calls in
> v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before
> v9fs_fid_add().
>
> Fixes: dafbe689736 ('9p fid refcount: cleanup p9_fid_put calls')
> Reported-by: syzbot+5b667f9a1fee4ba3775a@syzkaller.appspotmail.com
> Signed-off-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> ---
> fs/9p/vfs_inode_dotl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
> index 143ac03b7425..3397939fd2d5 100644
> --- a/fs/9p/vfs_inode_dotl.c
> +++ b/fs/9p/vfs_inode_dotl.c
> @@ -407,8 +407,8 @@ static int v9fs_vfs_mkdir_dotl(struct mnt_idmap *idmap,
> err);
> goto error;
> }
> - v9fs_fid_add(dentry, &fid);
> v9fs_set_create_acl(inode, fid, dacl, pacl);
> + v9fs_fid_add(dentry, &fid);
> d_instantiate(dentry, inode);
> err = 0;
> inc_nlink(dir);
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] fs/9p: fix NULL pointer dereference on mkdir
2025-03-13 13:29 ` Christian Schoenebeck
@ 2025-03-13 13:33 ` Dominique Martinet
0 siblings, 0 replies; 3+ messages in thread
From: Dominique Martinet @ 2025-03-13 13:33 UTC (permalink / raw)
To: Christian Schoenebeck
Cc: Eric Van Hensbergen, Latchesar Ionkov, v9fs, linux-kernel, syzbot
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-03-13 13:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-13 12:59 [PATCH] fs/9p: fix NULL pointer dereference on mkdir Christian Schoenebeck
2025-03-13 13:29 ` Christian Schoenebeck
2025-03-13 13:33 ` Dominique Martinet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).