Out-of-bounds write in GNU mtools during VFAT parsing

GNU mtools before 4.0.50 has an out-of-bounds write in parse_vses in vfat.c.

• GNU mtools: the CNA marks the semver range beginning at 0 and below 4.0.50 as affected. The affected modules are mdir and mcopy, and the affected program file is vfat.c.
• GNU mtools 4.0.50: the GNU release announcement identifies this release as fixing the issue.
• The available evidence does not reconcile downstream distribution package revisions or establish the status of later parallel branches. Package maintainers should map their builds to the upstream fix rather than infer status from a package label.

The defect is in parse_vses in vfat.c, which is called when vfat_lookup_loop_common processes directory entries with the VFAT long-name attribute 0x0f. The source checks and rejects values greater than MAX_VFAT_SUBENTRIES, but it does not perform an equivalent lower-bound check before using id - 1 in the status-bit update and v->name[...] index calculations. This is consistent with CWE-839, a numeric range comparison without a minimum check. At a high level, malformed or crafted VFAT directory-entry data in a disk image or removable medium could reach this parser when a user or process invokes mdir or mcopy; the specific input layout is not established by the available evidence. The result can be a write outside the intended memory region and corruption of the process memory. The evidence does not establish a reliable code-execution path or identify the exact object that is overwritten.

• Reachability: local processing path; the available evidence does not show that this is a network service vulnerability.
• Authentication: no privileges are required.
• User interaction: required, because a user or process must cause the utility to process the input.
• Complexity: low according to the supplied assessment.
• Exploitation status: the record does not identify a public exploit, and its known-exploited field is unset. The CISA enrichment attached to the returned CVE record marks exploitation as none and automatable as no, but that does not prove that future exploitation is impossible.

The flaw can cause a write outside the intended memory region of the mtools process while VFAT data is being parsed, leading to a crash or interrupted processing. The assessed consequences are primarily to availability, with limited integrity impact; no confidentiality impact is identified in the supplied data. The effect is confined to the mtools process in the available assessment, and the evidence does not show privilege escalation or a changed security scope. Arbitrary code execution is not established, so the issue should not automatically be treated as a confirmed takeover path.

An affected invocation can corrupt mtools process memory, terminate the utility, or disrupt workflows that inspect or copy files from VFAT media. The supplied impact assessment indicates no confidentiality impact, limited integrity impact, and a significant availability consequence. This could interrupt jobs or scripts that rely on mdir or mcopy, but the available evidence does not establish a specific breach, data-loss, or compromise scenario. Organizations should prioritize hosts and automation that process untrusted removable media or disk images.

1. Upgrade GNU mtools to 4.0.50, the release identified as fixing the issue.
2. Confirm that deployed mdir and mcopy binaries come from a build containing this release's fix. Do not infer safety from a package name without checking the distributor's mapping.
3. Until upgrade, avoid using affected binaries to process untrusted VFAT media or disk image files where practical, or isolate that processing path. This is a precautionary risk reduction, not a confirmed vendor workaround.
4. Rebuild and redeploy dependent images, jobs, and automation, then rescan inventory for copies of mtools bundled outside the primary package manager.

1. Inventory every installed copy of GNU mtools, including copies bundled in containers or statically integrated, and record release metadata. Compare it with the fixed release in remediation.
2. Identify hosts, jobs, and scripts that invoke mdir or mcopy, especially workflows that read removable media or disk image files.
3. Review crash reports and process-termination events for mtools invocations after VFAT input is processed. Treat this only as a precautionary signal, not as a vulnerability-specific indicator.
4. Where source builds are available, check whether vfat.c is present and whether the parser contains the upstream correction. Source inspection alone does not prove that deployed binaries are fixed.
5. The available evidence does not define a specific IOC or log signature. The absence of such telemetry does not establish safety.