From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga
Date: Wed, 09 Sep 2026 09:18:49 +0000 [thread overview]
Message-ID: <20260909091849.C5D7F1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260909-work-ntfs3-d_instantiate_new-v1-1-2db697162ce8@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] If `ntfs_init_acl()` fails, the error path skips the necessary cleanup for `ATTR_EA`, permanently leaking disk clusters allocated for non-resident extended attributes.
--
commit 44a39faac2ebabd21da92b47785ce2d1e97401b0
Author: Christian Brauner <brauner@kernel.org>
fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga
This commit fixes a bug where d_instantiate() was called on an I_NEW inode
before unlock_new_inode(). This caused lockdep lock owner corruption when
paths concurrently locked the directory. The fix switches to using
d_instantiate_new() and drops the trailing unlock_new_inode().
Closes: https://lore.kernel.org/6a9beced.a5e650b3.26d8a.000b.GAE@google.com
> diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
> index 56b4f6469a280..4ac26c80bd34f 100644
> --- a/fs/ntfs3/inode.c
> +++ b/fs/ntfs3/inode.c
[ ... ]
> @@ -1917,9 +1917,6 @@ int ntfs_create_inode(struct mnt_idmap *idmap, struct inode *dir,
> if (!fnd)
> ni_unlock(dir_ni);
>
> - if (!err)
> - unlock_new_inode(inode);
> -
> return err;
> }
[Severity: High]
This isn't a bug introduced by this patch, but does ntfs_create_inode()
permanently leak disk clusters if ntfs_init_acl() fails?
If ntfs_init_acl() returns an error, the error path jumps to out5:
fs/ntfs3/inode.c:ntfs_create_inode() {
...
#ifdef CONFIG_NTFS3_FS_POSIX_ACL
if (!S_ISLNK(mode) && (sb->s_flags & SB_POSIXACL)) {
err = ntfs_init_acl(idmap, inode, dir);
if (err)
goto out5;
} else
#endif
...
}
Jumping to out5 bypasses the out6 label, which contains the essential
cleanup logic for ATTR_EA:
out6:
attr = ni_find_attr(ni, NULL, NULL, ATTR_EA, NULL, 0, NULL, NULL);
if (attr && attr->non_res) {
/* Delete ATTR_EA, if non-resident. */
struct runs_tree run;
run_init(&run);
attr_set_size(ni, ATTR_EA, NULL, 0, &run, 0, NULL, false);
run_close(&run);
}
out5:
if (!S_ISDIR(mode))
...
If ntfs_init_acl() creates the first ACL (which allocates non-resident
clusters for ATTR_EA via ntfs_set_acl_ex -> ntfs_set_ea -> attr_set_size)
but fails on the second ACL (e.g. ENOMEM), the non-resident ATTR_EA is left
attached to the inode.
The error path then proceeds to out4, clearing RECORD_FLAG_IN_USE on the MFT
record. Later, when the inode is evicted and ni_clear() is called, it checks
is_rec_inuse(). Because the flag was cleared, ni_clear() skips calling
ni_delete_all(), which is the only other function capable of freeing
non-resident attribute clusters.
Could an unprivileged user repeatedly trigger this failure (e.g. by exhausting
memory) to systematically exhaust disk space?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-work-ntfs3-d_instantiate_new-v1-1-2db697162ce8@kernel.org?part=1
next prev parent reply other threads:[~2026-09-09 9:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 9:03 [PATCH] fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga Christian Brauner
2026-09-09 9:18 ` sashiko-bot [this message]
2026-09-09 11:11 ` Jan Kara
2026-09-10 7:22 ` Christian Brauner
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=20260909091849.C5D7F1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.