CVE-2026-53023

What it actually does

This is a Linux kernel ntfs3 filesystem information-disclosure flaw. When an NTFS volume is mounted, the kernel converts the on-disk UTF-16 volume label to UTF-8 and caches it in a fixed-size buffer. If the converted label exactly fills that buffer, the cached string is not NUL-terminated. Later, when the label is displayed as a C string, the kernel can read beyond the end of the label buffer until it finds a terminator, potentially exposing adjacent kernel memory to a local user who can read the label interface. The primary impact is kernel memory disclosure, which may assist further exploitation by leaking pointers or other sensitive in-kernel data.

Why it matters to the business

Successful exploitation could allow a local attacker or someone able to cause a crafted NTFS volume to be mounted to disclose kernel memory. On its own, this is not expected to provide remote code execution or immediate system compromise, and current public exploitation signals are low: EPSS is 0.00123, it is not listed in CISA KEV, and no mature exploit is reported. However, kernel memory disclosure can weaken platform defenses such as address randomization and may be useful as part of a larger exploit chain, especially on systems that routinely mount removable media or untrusted disk images.

How an attack unfolds

An attacker prepares an NTFS filesystem whose volume label converts from UTF-16 to a UTF-8 byte sequence that exactly fills the kernel ntfs3 label buffer. The attacker then needs that filesystem to be mounted using the in-kernel ntfs3 driver, either by mounting it locally, convincing an operator to mount removable media, or triggering automated handling of disk images. During mount, the kernel caches the converted label without a terminating NUL byte. When the label is later read through the kernel’s label display path, the `%s` formatting operation continues reading beyond the buffer boundary until it encounters a NUL byte. The returned label data may therefore include bytes from adjacent kernel memory. The attacker collects the leaked bytes and may use them to infer kernel memory layout or support a follow-on local privilege-escalation attempt.

How to fix it

Upgrade to a Linux kernel build that includes the ntfs3 fix which explicitly terminates the cached converted volume label and clamps the exact-full-buffer case. If vendor fixed package versions are available for the distribution in use, apply those kernel updates rather than attempting to patch the filesystem manually. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting NTFS filesystems, disabling or restricting removable-media automount, avoiding automated mounting of untrusted disk images, using strict mount policies, and considering temporary avoidance of the in-kernel ntfs3 driver for untrusted NTFS volumes.

How to confirm the fix worked

Confirm that the running kernel package or custom kernel source includes the ntfs3 change that NUL-terminates `sbi->volume.label` after `utf16s_to_utf8s()` and clamps full-buffer conversions. Validate operational exposure by checking whether systems allow NTFS mounts through the `ntfs3` driver, whether removable media or disk images are automatically mounted, and whether unprivileged users can initiate mounts through desktop services, udisks, containers, or delegated mount helpers. After patching, reboot into the updated kernel and verify the active kernel version, not only the installed package version.

Typical attack path

1. Prepare or obtain an NTFS volume with a crafted volume label that exactly fills the converted UTF-8 label buffer.
2. Get the crafted NTFS volume mounted with the Linux kernel ntfs3 driver.
3. Trigger the label display/read path exposed by the ntfs3 filesystem implementation.
4. Capture the returned label output and inspect any bytes appended beyond the legitimate label.
5. Use leaked kernel memory, if useful, to support additional exploitation such as bypassing kernel address-space randomization.

How to detect it

Look for evidence that untrusted or unusual NTFS volumes were mounted using the in-kernel `ntfs3` driver, followed by reads of the filesystem label interface. Useful sources include Linux audit logs for `mount` syscalls, systemd journal entries, kernel logs, udisks or desktop automount logs, EDR process telemetry, shell history on interactive systems, and forensic timelines for removable media or disk-image attachment. This flaw may not generate a crash or obvious kernel error, so detection is primarily behavioral: identify recent `ntfs3` mounts, especially from USB/removable devices, loop devices, or user-controlled disk images, and correlate them with processes reading ntfs3 sysfs/proc label attributes. If kernel memory leakage is suspected, preserve the mounted image, process telemetry, audit logs, shell history, and journal/kernel logs for analysis. There are no reliable network indicators because exploitation is local and filesystem-driven.

• ntfs3
• type=ntfs3
• fstype=ntfs3
• mount -t ntfs3
• /sys/fs/ntfs3
• ntfs3_label_show
• ntfs_fill_super
• utf16s_to_utf8s
• /dev/loop
• udisksd

What your security team should do

• Prioritize patching systems that mount removable media, forensic images, backup media, user-supplied virtual disks, or other untrusted NTFS volumes.
• Ensure updated kernel packages are installed and systems are rebooted into the fixed kernel.
• Temporarily restrict or disable automount of NTFS media on workstations, kiosks, shared Linux hosts, and analysis systems until patched.
• Review mount policies to ensure unprivileged users cannot mount arbitrary NTFS filesystems unless explicitly required.
• Monitor for recent `ntfs3` mounts from removable devices or disk-image workflows, especially on systems where untrusted users have local access.
• Treat any confirmed kernel memory disclosure as potentially useful for exploit chaining and investigate for accompanying local privilege-escalation activity.