CVE-2026-72470 Linux CVE debrief

Who should care

Linux kernel developers, ntfs3 filesystem users, and administrators responsible for maintaining Linux systems should be aware of this vulnerability. They should verify and apply the kernel patch to update the ntfs3 driver, use compensating controls such as mounting the NTFS volume with a smaller log page size, and monitor system logs for potential buffer overflow errors. Additionally, they should review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance, and plan vendor-supported updates or mitigations through normal change control where exposure is confirmed. Affected product deployments should be identified in managed environments, and an owner should be assigned for follow-up. Relevant monitoring, detection, and logs should be checked for exposed assets that need extra review. Exceptions should be tracked, and remediated assets should be retested and closed only after evidence is documented. Asset inventory and rollback/change windows should also be considered as part of the remediation process. Source tracking and exposure review are also recommended to ensure comprehensive vulnerability management. Compensating controls should be reviewed for exposed systems while remediation is scheduled and verified. This requires coordination between Linux kernel developers, ntfs3 filesystem users, and administrators responsible for maintaining Linux systems to ensure effective vulnerability management and mitigation. The vulnerability management process should include verifying affected product deployments, reviewing official advisories, planning updates or mitigations, and tracking exceptions and retesting remediated assets. Security teams should prioritize this vulnerability based on its potential impact and ensure that necessary measures are taken to mitigate it. This includes monitoring system logs, reviewing compensating controls, and verifying that kernel patches are applied and effective. By taking these steps, Linux kernel developers, ntfs3 filesystem users, and administrators can effectively manage and mitigate this vulnerability. Vulnerability management and security teams should work together to ensure that

Technical summary

The Linux kernel's ntfs3 filesystem driver has a vulnerability that can lead to a buffer overflow when mounting a dirty NTFS volume. The issue arises when the log page size adopted from the on-disk log exceeds the size of the scratch buffer 'one_page_buf'. The buffer is initially allocated using the page size chosen from the host PAGE_SIZE. However, when a restart area is found, the log page size recorded on disk is adopted, and the buffer is not resized accordingly. To fix this, the buffer should be resized to accommodate the new page size. This can be achieved by growing the 'one_page_buf' when the adopted on-disk page size exceeds the size used for the initial allocation.

Defensive priority

Medium

Recommended defensive actions

• Verify and apply the kernel patch to update the ntfs3 driver
• Use a compensating control, such as mounting the NTFS volume with a smaller log page size
• Monitor system logs for potential buffer overflow errors
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• Check relevant monitoring, detection, and logs for exposed assets that need extra review

Evidence notes

The vulnerability exists in the Linux kernel's ntfs3 filesystem driver. When a dirty NTFS volume is mounted, the log page size is adopted from the on-disk log. However, the scratch buffer 'one_page_buf' is not resized to accommodate the new page size, leading to a potential buffer overflow. The issue is reachable when mounting a dirty NTFS volume with a log page size larger than the buffer initially allocated on the mounting host.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.