From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-72478: fs/ntfs3: add bounds check to run_get_highest_vcn()
Date: Sat, 15 Aug 2026 15:09:17 +0900 [thread overview]
Message-ID: <2026081536-CVE-2026-72478-33c2@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: add bounds check to run_get_highest_vcn()
run_get_highest_vcn() parses a packed NTFS mapping-pairs buffer without
any length bound, relying solely on a 0x00 terminator to stop. A
crafted $LogFile UpdateMappingPairs record whose embedded attribute
contains mapping-pairs runs without a terminator causes the function to
read past the slab allocation, triggering a KASAN slab-out-of-bounds
read on mount.
The sibling function run_unpack() received an analogous bounds-check in
commit b62567bca474 ("ntfs3: add buffer boundary checks to run_unpack()"),
but run_get_highest_vcn() was missed.
Take a run_buf_size parameter and reject any run header whose payload
would extend past the buffer end, mirroring the pattern used by
run_unpack(). The caller in fslog.c passes the remaining attribute
bytes after the mapping-pairs offset.
KASAN report (on mainline v7.1 merge window HEAD):
BUG: KASAN: slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410
Read of size 1 at addr ffff88800e2d5400 by task mount/72
Call Trace:
run_get_highest_vcn+0x3c0/0x410
do_action.isra.0+0x3ba8/0x7b50
log_replay+0x9ddd/0x10200
ntfs_loadlog_and_replay+0x4ad/0x610
ntfs_fill_super+0x214a/0x4540
The Linux kernel CVE team has assigned CVE-2026-72478 to this issue.
Affected and fixed versions
===========================
Issue introduced in 6.1.175 with commit 425de2aba0d061b3e715d51a3b1992c112ed5b99 and fixed in 6.1.178 with commit c69b9003332917b652175d5fa9d84158c5ed8617
Issue introduced in 6.6.140 with commit bf7ac4a1d3bfc6e56e54635c3d331a68170d37c9 and fixed in 6.6.145 with commit 8afc24a884aff6a6f08028bd779ee65c40054455
Issue introduced in 6.12.86 with commit e64f7dfcaff79e7dfff9121a382dd77f9b462f62 and fixed in 6.12.97 with commit c23083b472a720c3f60b147db05b25b751c7c1bf
Issue introduced in 6.18.27 with commit d3012690a7065d9ca86521a525ad11e8af491d45 and fixed in 6.18.40 with commit a31893206588374d7d16fad387189d8165c7efd3
Issue introduced in 7.1 with commit b62567bca47408e6739dee75f02a2113548af875 and fixed in 7.1.5 with commit 41081202eb823f5b27ff164b12010b24428100ad
Issue introduced in 7.1 with commit b62567bca47408e6739dee75f02a2113548af875 and fixed in 7.2-rc1 with commit bb11485a87fbb2254b62cfed630b699d50e57da8
Issue introduced in 5.15.209 with commit bbad75336870b51b81979b97613746237fcb02fe
Issue introduced in 7.0.4 with commit 41aadf5cb482793a24e05aa136224e179a778586
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-72478
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
fs/ntfs3/fslog.c
fs/ntfs3/ntfs_fs.h
fs/ntfs3/run.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/c69b9003332917b652175d5fa9d84158c5ed8617
https://git.kernel.org/stable/c/8afc24a884aff6a6f08028bd779ee65c40054455
https://git.kernel.org/stable/c/c23083b472a720c3f60b147db05b25b751c7c1bf
https://git.kernel.org/stable/c/a31893206588374d7d16fad387189d8165c7efd3
https://git.kernel.org/stable/c/41081202eb823f5b27ff164b12010b24428100ad
https://git.kernel.org/stable/c/bb11485a87fbb2254b62cfed630b699d50e57da8
reply other threads:[~2026-08-15 6:30 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=2026081536-CVE-2026-72478-33c2@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@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 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.