From: Karl Mehltretter <kmehltretter@gmail.com>
To: Namjae Jeon <linkinjeon@kernel.org>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
Hyunchul Lee <hyc.lee@gmail.com>,
ntfs@lists.linux.dev, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/2] ntfs: fix kunmap_local() of advanced pointers in check_mft_mirror()
Date: Tue, 6 Oct 2026 06:51:35 +0200 [thread overview]
Message-ID: <20261006045136.5911-2-kmehltretter@gmail.com> (raw)
In-Reply-To: <20261006045136.5911-1-kmehltretter@gmail.com>
check_mft_mirror() compares the mft records of a page with the mirror
records by advancing kmft and kmirr by the record size for every record.
It then passes the advanced pointers to kunmap_local(). After the last
record of a page they point one page past the mapping.
With HIGHMEM kunmap_local() warns that the address does not match the
top of the kmap_local stack. What it does next depends on how the
architecture finds the page table entry:
- 32-bit ARM looks the entry up by that address. It clears the entry of
the neighbouring fixmap slot and leaves the real mapping in place.
The next kmap_local() on that CPU that reaches the slot hits the
BUG_ON(!pte_none()) in __kmap_local_pfn_prot().
- x86-32 takes the entry from the stack index, so the wrong address
does not select a wrong entry. In QEMU the mount carried on after the
warning.
With 4 KiB pages and 1 KiB mft records the four mirror records fill
exactly one page, so every mount whose $MFT and $MFTMirr folios are in
highmem hits it. A fresh mkntfs volume on 32-bit ARM
(multi_v7_defconfig, 256 MiB of highmem) fails on the first mount:
WARNING: mm/highmem.c:623 at kunmap_local_indexed+0x254/0x26c, CPU#1: mount/85
kunmap_local_indexed from ntfs_fill_super+0x224c/0x35a0
ntfs_fill_super from get_tree_bdev_flags+0x1d8/0x2a4
ntfs: volume version 3.1, dev loop0, cluster size 4096
kernel BUG at mm/highmem.c:565!
PC is at __kmap_local_pfn_prot+0x210/0x214
__kmap_local_page_prot from ntfs_check_logfile+0x1fc/0x1210
Found with syzkaller. Kernels without HIGHMEM do not show it.
kmap_local_folio() returns the direct map address there and
kunmap_local() has no mapping to remove.
Keep the addresses returned by kmap_local_folio() and unmap with those.
Fixes: 6251f0b0de7d ("ntfs: update super block operations")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Tested in QEMU on mainline 551c722f4080 with a fresh mkntfs volume and
with the syzkaller program that found the bug.
ARM multi_v7_defconfig plus KCOV, virt, cortex-a15, 2 CPUs,
1 GiB RAM, 256 MiB highmem
x86-32 i386_defconfig plus HIGHMEM4G and NTFS_FS, q35, 2 CPUs,
2 GiB RAM, 1.1 GiB highmem
In the table, warning is the WARNING at mm/highmem.c:623 and BUG is
the one at mm/highmem.c:565.
mainline with this patch
ARM, mount warning, then BUG 3 mounts clean
ARM, syzkaller program warning, then BUG 3 runs clean
x86-32, mount warning, no BUG warning gone
x86-32 still warns when mount(2) returns. That is the bug fixed by
patch 2.
The other kmap_local users in fs/ntfs unmap an address inside the
mapped page. Only check_mft_mirror() advances the pointer it later
unmaps.
fs/ntfs/super.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 4066bacabe37..a53f9997c152 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -959,7 +959,7 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
struct super_block *sb = vol->sb;
struct ntfs_inode *mirr_ni;
struct folio *mft_folio = NULL, *mirr_folio = NULL;
- u8 *kmft = NULL, *kmirr = NULL;
+ u8 *kmft = NULL, *kmirr = NULL, *kmft_base = NULL, *kmirr_base = NULL;
struct runlist_element *rl, rl2[2];
pgoff_t index;
int mrecs_per_page, i;
@@ -974,9 +974,9 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
/* Switch pages if necessary. */
if (!(i % mrecs_per_page)) {
if (index) {
- kunmap_local(kmirr);
+ kunmap_local(kmirr_base);
folio_put(mirr_folio);
- kunmap_local(kmft);
+ kunmap_local(kmft_base);
folio_put(mft_folio);
}
/* Get the $MFT page. */
@@ -986,7 +986,8 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
ntfs_error(sb, "Failed to read $MFT.");
return false;
}
- kmft = kmap_local_folio(mft_folio, 0);
+ kmft_base = kmap_local_folio(mft_folio, 0);
+ kmft = kmft_base;
/* Get the $MFTMirr page. */
mirr_folio = read_mapping_folio(vol->mftmirr_ino->i_mapping,
index, NULL);
@@ -994,7 +995,8 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
ntfs_error(sb, "Failed to read $MFTMirr.");
goto mft_unmap_out;
}
- kmirr = kmap_local_folio(mirr_folio, 0);
+ kmirr_base = kmap_local_folio(mirr_folio, 0);
+ kmirr = kmirr_base;
++index;
}
@@ -1006,10 +1008,10 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
"Incomplete multi sector transfer detected in mft record %i.",
i);
mm_unmap_out:
- kunmap_local(kmirr);
+ kunmap_local(kmirr_base);
folio_put(mirr_folio);
mft_unmap_out:
- kunmap_local(kmft);
+ kunmap_local(kmft_base);
folio_put(mft_folio);
return false;
}
@@ -1045,9 +1047,9 @@ static bool check_mft_mirror(struct ntfs_volume *vol)
kmirr += vol->mft_record_size;
} while (++i < vol->mftmirr_size);
/* Release the last folios. */
- kunmap_local(kmirr);
+ kunmap_local(kmirr_base);
folio_put(mirr_folio);
- kunmap_local(kmft);
+ kunmap_local(kmft_base);
folio_put(mft_folio);
/* Construct the mft mirror runlist by hand. */
--
2.53.0
next prev parent reply other threads:[~2026-10-06 4:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 4:51 [PATCH v2 0/2] ntfs: fix two kmap_local bugs on 32-bit kernels Karl Mehltretter
2026-10-06 4:51 ` Karl Mehltretter [this message]
2026-10-06 4:51 ` [PATCH v2 2/2] ntfs: fix kmap_local leak in ntfs_check_logfile() Karl Mehltretter
2026-10-06 6:04 ` [PATCH v2 0/2] ntfs: fix two kmap_local bugs on 32-bit kernels Hyunchul Lee
2026-10-06 13:29 ` Namjae Jeon
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=20261006045136.5911-2-kmehltretter@gmail.com \
--to=kmehltretter@gmail.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs@lists.linux.dev \
--cc=stable@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
all inboxes | Powered by JetHome®