From: "syzbot" <syzbot@kernel.org>
To: syzkaller-upstream-moderation@googlegroups.com
Cc: syzbot@lists.linux.dev
Subject: [PATCH RFC] autofs: fix memory and pipe leaks on fill_super error paths
Date: Wed, 2 Sep 2026 18:56:02 +0000 (UTC) [thread overview]
Message-ID: <f8aa6092-be10-4318-96f5-e3ea86e416c3@mail.kernel.org> (raw)
During autofs superblock initialization in autofs_fill_super(), two
resource leak issues can occur on error paths:
First, autofs_fill_super() allocates a root autofs_info structure via
autofs_new_ino() prior to allocating the root inode via autofs_get_inode().
If autofs_get_inode() fails (for instance, under memory pressure),
autofs_fill_super() returns -ENOMEM directly without freeing the allocated
autofs_info structure. Because the autofs_info has not yet been attached to
the root dentry (s->s_root->d_fsdata), standard VFS superblock cleanup
cannot free it, leading to a memory leak:
BUG: memory leak
unreferenced object 0xffff8881074fbc00 (size 192):
backtrace (crc 69a9bad1):
__kmalloc_cache_noprof+0x1b7/0x400 mm/slub.c:5559
autofs_new_ino fs/autofs/inode.c:16 [inline]
autofs_fill_super+0x74/0x280 fs/autofs/inode.c:321
vfs_get_super fs/super.c:1405 [inline]
get_tree_nodev+0x6f/0xc0 fs/super.c:1424
vfs_get_tree+0x3a/0x130 fs/super.c:1947
vfs_cmd_create+0x6d/0x110 fs/fsopen.c:231
__se_sys_fsconfig+0x5b8/0x6f0 fs/fsopen.c:350
do_syscall_64+0x126/0x350 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Second, struct autofs_sb_info is initialized with the AUTOFS_SBI_CATATONIC
flag set in autofs_alloc_sbi(), and sbi->pipe is populated when parsing the
control pipe file descriptor. The AUTOFS_SBI_CATATONIC flag is cleared only
at the very end of autofs_fill_super(). If autofs_fill_super() fails before
clearing this flag, VFS superblock destruction calls autofs_kill_sb(),
which calls autofs_catatonic_mode(sbi). However, autofs_catatonic_mode()
checked if AUTOFS_SBI_CATATONIC was already set and returned immediately
without releasing sbi->pipe via fput(), resulting in a leaked pipe file
reference.
Fix these leaks by:
1. Reordering root inode and root dentry creation in autofs_fill_super() so
that autofs_new_ino() is called only after s->s_root is successfully
created. If autofs_get_inode() or d_make_root() fails, no autofs_info has
been allocated yet. Once autofs_new_ino() succeeds, it is immediately
attached to s->s_root->d_fsdata, ensuring that any subsequent failure in
autofs_fill_super() properly cleans it up via autofs_dentry_release()
during superblock teardown.
2. Updating autofs_catatonic_mode() to check and release sbi->pipe via
fput() and reset sbi->pipe and sbi->pipefd even if AUTOFS_SBI_CATATONIC is
already set.
Fixes: 66917f85db60 ("autofs: add: new_inode check in autofs_fill_super()")
Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+df1db6e034b3953e19f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=df1db6e034b3953e19f5
Link: https://syzkaller.appspot.com/ai_job?id=fb78862e-8c53-4157-80dc-3813ad0b70f3
To: <autofs@vger.kernel.org>
To: "Ian Kent" <raven@themaw.net>
Cc: <linux-kernel@vger.kernel.org>
---
diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c
index c1e210cec..1e2078ee9 100644
--- a/fs/autofs/inode.c
+++ b/fs/autofs/inode.c
@@ -315,13 +315,6 @@ static int autofs_fill_super(struct super_block *s, struct fs_context *fc)
set_default_d_op(s, &autofs_dentry_operations);
s->s_time_gran = 1;
- /*
- * Get the root inode and dentry, but defer checking for errors.
- */
- ino = autofs_new_ino(sbi);
- if (!ino)
- return -ENOMEM;
-
root_inode = autofs_get_inode(s, S_IFDIR | 0755);
if (!root_inode)
return -ENOMEM;
@@ -332,10 +325,12 @@ static int autofs_fill_super(struct super_block *s, struct fs_context *fc)
root_inode->i_op = &autofs_dir_inode_operations;
s->s_root = d_make_root(root_inode);
- if (unlikely(!s->s_root)) {
- autofs_free_ino(ino);
+ if (unlikely(!s->s_root))
+ return -ENOMEM;
+
+ ino = autofs_new_ino(sbi);
+ if (!ino)
return -ENOMEM;
- }
s->s_root->d_fsdata = ino;
if (ctx->pgrp_set) {
diff --git a/fs/autofs/waitq.c b/fs/autofs/waitq.c
index d46241342..a07ae8396 100644
--- a/fs/autofs/waitq.c
+++ b/fs/autofs/waitq.c
@@ -18,6 +18,11 @@ void autofs_catatonic_mode(struct autofs_sb_info *sbi)
mutex_lock(&sbi->wq_mutex);
if (sbi->flags & AUTOFS_SBI_CATATONIC) {
+ if (sbi->pipe) {
+ fput(sbi->pipe);
+ sbi->pipe = NULL;
+ sbi->pipefd = -1;
+ }
mutex_unlock(&sbi->wq_mutex);
return;
}
@@ -37,9 +42,11 @@ void autofs_catatonic_mode(struct autofs_sb_info *sbi)
kfree(wq);
wq = nwq;
}
- fput(sbi->pipe); /* Close the pipe */
- sbi->pipe = NULL;
- sbi->pipefd = -1;
+ if (sbi->pipe) {
+ fput(sbi->pipe); /* Close the pipe */
+ sbi->pipe = NULL;
+ sbi->pipefd = -1;
+ }
mutex_unlock(&sbi->wq_mutex);
}
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
--
This is an AI-generated patch subject to moderation.
Reply with '#syz upstream' to Sign-off the patch as a human author
and send it to the upstream kernel mailing lists.
Reply with '#syz reject' to reject it ('#syz unreject' to undo).
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.
reply other threads:[~2026-09-02 18:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f8aa6092-be10-4318-96f5-e3ea86e416c3@mail.kernel.org \
--to=syzbot@kernel.org \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-upstream-moderation@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox