CVE-2026-72470 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: resize log->one_page_buf when adopting on-disk page size
log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE:
log->one_page_buf = kmalloc(log->page_size, GFP_NOFS);
Later, when a restart area is found, the log page size recorded on disk is adopted:
t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); if (log->page_size != t32) {
log->l_size = log->orig_file_size; log->page_size = norm_file_page(t32, &log->l_size, t32 == DefaultLogPageSize); }
If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer:
page_buf = page_off ? log->one_page_buf : *buffer; err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, log->page_size, NULL, &log->read_ahead);
overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer).
Grow one_page_buf when the adopted on-disk page size exceeds the size used for the initial allocation. On krealloc() failure the original buffer is left intact and freed by the existing error path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the linux kernel's ntfs3 filesystem implementation where a memory corruption flaw occurs during ntfs volume mounting operations. The issue stems from improper buffer management when handling different page sizes between host systems and on-disk log structures. When the ntfs3 driver initializes, it allocates a scratch buffer called one_page_buf using the host system's PAGE_SIZE value which is typically 4KB on most modern systems. However, during the log replay process, the driver discovers that the on-disk restart information contains a different page size specification that may be larger than the initially allocated buffer.
The technical flaw manifests when the driver encounters a dirty ntfs volume where the log was formatted with a larger page size than what was allocated initially. The code correctly updates the log->page_size variable to match the on-disk page size, but fails to resize the one_page_buf accordingly. This creates a scenario where the buffer remains at its original smaller size while the page_size parameter grows to accommodate the larger on-disk format. According to the common weakness enumeration standard CWE-129, this represents an improper boundary condition error where buffer boundaries are not properly validated against actual usage requirements.
The operational impact occurs during mount operations when unaligned read_log_page() function attempts to read the full page_size bytes into the undersized one_page_buf scratch buffer. This results in a classic buffer overflow condition where data written beyond the allocated buffer boundaries can overwrite adjacent memory locations. The vulnerability is particularly dangerous because it can be triggered by mounting a dirty ntfs volume with specific log formatting characteristics, making it exploitable during normal system operations.
The attack pattern follows the MITRE ATT&CK framework's technique T1059.001 for command and script injection through kernel-level memory corruption. This vulnerability can potentially lead to privilege escalation or system instability when exploited by malicious actors who can craft specific ntfs filesystem structures. The risk is elevated when systems mount volumes from different environments where page size configurations may differ significantly.
The suggested mitigation involves implementing proper buffer reallocation when the on-disk page size exceeds the initial allocation. The solution requires growing one_page_buf using krealloc() when the adopted page size is larger than the original allocation, ensuring that memory boundaries match actual usage requirements. This approach follows secure coding practices and maintains consistency with the existing error handling paths in the codebase. When krealloc() fails, the original buffer remains intact and is properly freed through existing error handling mechanisms, preventing resource leaks while maintaining system stability.
This vulnerability represents a classic case of inadequate input validation and memory management in kernel space filesystem drivers, similar to other buffer overflow issues documented in security literature. The fix ensures that buffer allocation matches actual requirements regardless of runtime conditions, preventing the exploitation scenario where different page size configurations create memory corruption opportunities. The resolution addresses both the immediate memory safety concern and maintains compatibility with existing ntfs volume formats while ensuring robust operation across different host environments.