[PATCH] d_path: fall back to init_fs when called after exit_fs()

[PATCH] d_path: fall back to init_fs when called after exit_fs()

[Nguyen Ngoc Thang]

d_path() dereferences current->fs unconditionally. do_exit() runs
exit_fs() before exit_task_work(), so a deferred __fput() sees
current->fs == NULL. If that fput ends up in d_path(), it crashes:

  ima_file_free() -> ima_update_xattr() -> ima_calc_file_hash()
    -> dentry_open() -> smack_file_open() -> smack_log()
    -> common_lsm_audit() -> audit_log_d_path() -> d_path()
    -> read_seqbegin(&current->fs->seq)

Any LSM or audit path that formats a path on open can hit this. Fall
back to init_fs, whose root is always valid, when the task has no fs.

Reported-by: syzbot+975ace299d6ba2eb1cea@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=975ace299d6ba2eb1cea
Fixes: 4a9d4b024a31 ("switch fput to task_work_add")
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
---
Reproduced in QEMU (x86_64, KASAN, Smack+IMA+audit) with the syzbot C
reproducer: without the patch the first exiting child hits a null-ptr-deref
in d_path(); with it the reproducer runs to completion with no KASAN/Oops.

Alternatives considered: fixing only the IMA->Smack audit path (too narrow,
any open-time LSM/audit hook can hit this), or reordering exit_fs() and
exit_task_work() (too invasive). Happy to rework if you prefer another approach.

 fs/d_path.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/d_path.c b/fs/d_path.c
index c25309006d5d..24fd56e80631 100644
--- a/fs/d_path.c
+++ b/fs/d_path.c
@@ -3,6 +3,7 @@
 #include <linux/export.h>
 #include <linux/uaccess.h>
 #include <linux/fs_struct.h>
+#include <linux/init_task.h>
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/prefetch.h>
@@ -284,7 +285,8 @@ char *d_path(const struct path *path, char *buf, int buflen)
 		return path->dentry->d_op->d_dname(path->dentry, buf, buflen);
 
 	rcu_read_lock();
-	get_fs_root_rcu(current->fs, &root);
+	/* exit_fs() already ran if we are called from exit_task_work() */
+	get_fs_root_rcu(current->fs ?: &init_fs, &root);
 	if (unlikely(d_unlinked(path->dentry)))
 		prepend(&b, " (deleted)", 11);
 	else
-- 
2.43.0

Re: [PATCH] d_path: fall back to init_fs when called after exit_fs()

[Al Viro]

On Mon, Oct 19, 2026 at 08:24:19PM +0700, Nguyen Ngoc Thang wrote:
> d_path() dereferences current->fs unconditionally. do_exit() runs
> exit_fs() before exit_task_work(), so a deferred __fput() sees
> current->fs == NULL. If that fput ends up in d_path(), it crashes:
> 
>   ima_file_free() -> ima_update_xattr() -> ima_calc_file_hash()
>     -> dentry_open() -> smack_file_open() -> smack_log()
>     -> common_lsm_audit() -> audit_log_d_path() -> d_path()
>     -> read_seqbegin(&current->fs->seq)
> 
> Any LSM or audit path that formats a path on open can hit this. Fall
> back to init_fs, whose root is always valid, when the task has no fs.
> 
> Reported-by: syzbot+975ace299d6ba2eb1cea@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=975ace299d6ba2eb1cea
> Fixes: 4a9d4b024a31 ("switch fput to task_work_add")
> Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
> ---
> Reproduced in QEMU (x86_64, KASAN, Smack+IMA+audit) with the syzbot C
> reproducer: without the patch the first exiting child hits a null-ptr-deref
> in d_path(); with it the reproducer runs to completion with no KASAN/Oops.
> 
> Alternatives considered: fixing only the IMA->Smack audit path (too narrow,
> any open-time LSM/audit hook can hit this), or reordering exit_fs() and
> exit_task_work() (too invasive). Happy to rework if you prefer another approach.

How about "don't use d_path() in places where current root is not well-defined"?

The reason why it tries to access current->fs is that it tries to produce
a pathname in caller's namespace, relative to whatever the caller happens to
be chrooted into.

Using that on final fput is insane - it might happen in context of completely
unexpected process.  So instead of papering over a symptom in d_path() itself,
the right approach would be to ask what do we expect from the data produced
by that call; "garbage string" is less obvious than an oops, but it's still
misleading.