From: DaeMyung Kang <charsyam@gmail.com>
To: linkinjeon@kernel.org, hyc.lee@gmail.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
DaeMyung Kang <charsyam@gmail.com>
Subject: [PATCH] ntfs: fix default_upcase refcount underflow and UAF on fs_context teardown
Date: Tue, 5 May 2026 22:07:52 +0900 [thread overview]
Message-ID: <20260505130752.3906509-1-charsyam@gmail.com> (raw)
ntfs_init_fs_context() allocates a fresh ntfs_volume with vol->upcase
left as NULL. ntfs_free_fs_context() unconditionally calls
ntfs_volume_free() during fs_context teardown, even when ntfs_fill_super()
never ran or already cleaned up. ntfs_volume_free() then executes:
mutex_lock(&ntfs_lock);
if (vol->upcase == default_upcase) {
ntfs_nr_upcase_users--;
vol->upcase = NULL;
}
When the global default_upcase is also NULL (very first mount attempt,
or all prior mounts have released the table), the comparison is
NULL == NULL, and ntfs_nr_upcase_users is decremented even though this
volume never claimed a reference. ntfs_nr_upcase_users is unsigned long,
so the decrement wraps to ULONG_MAX.
A subsequent successful mount can then free the shared table while the
mounted volume still points at it:
1. ntfs_fill_super() does the temporary ntfs_nr_upcase_users++ at the
"Generate the global default upcase table if necessary" block. With
the prior wraparound this brings the counter back to 0.
2. If the volume's $UpCase matches the default, the match path does
ntfs_nr_upcase_users++ and sets vol->upcase = default_upcase. The
counter is now 1.
3. On the success path, !--ntfs_nr_upcase_users evaluates true and
default_upcase is kvfree()'d while vol->upcase still points at it.
Subsequent upcase comparisons through that mount touch freed
memory.
This was reproduced with KASAN by closing a fresh fsopen("ntfs") context,
then mounting an NTFS image whose $UpCase table matches
generate_default_upcase(), and finally doing a case-insensitive lookup.
KASAN reports the dangling vol->upcase access:
BUG: KASAN: use-after-free in ntfs_collate_names+0x3b4/0x420
Read of size 2 at addr ffff888008d40048 by task init/1
ntfs_collate_names+0x3b4/0x420
ntfs_lookup_inode_by_name+0x1921/0x3130
ntfs_lookup+0x193/0xc40
vfs_statx+0xc7/0x190
vfs_fstatat+0x4b/0xa0
__do_sys_newfstatat+0x92/0xf0
The same QEMU reproducer was rerun after this change with KASAN
enabled. It reached "reproducer finished", and the log contained no
KASAN, use-after-free, Oops, or panic signatures.
Guard each comparison with an explicit vol->upcase non-NULL check so a
volume that never took a reference cannot decrement the global users
counter. Apply the same guard to the other default_upcase release sites
so all cleanup paths follow the same ownership rule: only volumes that
actually hold a default_upcase reference may drop one.
Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"")
Signed-off-by: DaeMyung Kang <charsyam@gmail.com>
---
fs/ntfs/super.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 22dc7865eca7..e9de84fb8297 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -1671,7 +1671,7 @@ static bool load_system_files(struct ntfs_volume *vol)
iput_upcase_err_out:
vol->upcase_len = 0;
mutex_lock(&ntfs_lock);
- if (vol->upcase == default_upcase) {
+ if (vol->upcase && vol->upcase == default_upcase) {
ntfs_nr_upcase_users--;
vol->upcase = NULL;
}
@@ -1701,7 +1701,7 @@ static void ntfs_volume_free(struct ntfs_volume *vol)
* the number of upcase users if we are a user.
*/
mutex_lock(&ntfs_lock);
- if (vol->upcase == default_upcase) {
+ if (vol->upcase && vol->upcase == default_upcase) {
ntfs_nr_upcase_users--;
vol->upcase = NULL;
}
@@ -2494,7 +2494,7 @@ static int ntfs_fill_super(struct super_block *sb, struct fs_context *fc)
}
vol->upcase_len = 0;
mutex_lock(&ntfs_lock);
- if (vol->upcase == default_upcase) {
+ if (vol->upcase && vol->upcase == default_upcase) {
ntfs_nr_upcase_users--;
vol->upcase = NULL;
}
--
2.43.0
reply other threads:[~2026-05-05 13:07 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=20260505130752.3906509-1-charsyam@gmail.com \
--to=charsyam@gmail.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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