CVE-2026-64323

What it actually does

This is a Linux kernel UDF filesystem memory-safety flaw in VAT 2.0 handling. When loading a UDF image with a virtual allocation table, the kernel trusts the attacker-controlled VAT header length from disk without verifying that it fits inside the VAT inode. If the header length is larger than the inode size, an unsigned subtraction underflows and produces an excessively large entry count. Subsequent virtual block translation can then read past the end of inline inode data, causing an out-of-bounds kernel memory read. Practical effects are primarily local kernel information disclosure and potential kernel crash or denial of service during mount or access of a crafted UDF filesystem image.

Why it matters to the business

An attacker who can cause a vulnerable Linux system to mount or process a malicious UDF filesystem image can potentially crash the host or expose sensitive kernel memory. The most relevant operational risks are instability of workstations, servers, forensic/media-processing systems, backup systems, and automated pipelines that inspect disk images, ISO files, optical media, or removable storage. This is not currently listed in CISA KEV, has no known public exploitation maturity in the provided data, and has low EPSS, so urgency is lower than for remotely exploitable internet-facing flaws; however, kernel memory corruption bugs should still be patched promptly because exploitation reliability can improve over time.

How an attack unfolds

An attacker creates a malformed UDF filesystem image containing a virtual partition with a VAT 2.0 header whose lengthHeader field is larger than the VAT inode size. The attacker then needs the target system to mount or otherwise parse that image using the vulnerable Linux kernel UDF driver. This may occur through a local user mounting an image, insertion of malicious removable media, automated handling of uploaded disk images, backup/archive processing, or privileged helper workflows that mount user-supplied filesystems. During udf_load_vat(), the kernel records the invalid start offset and calculates the number of VAT entries using an underflowed subtraction. Later, when the filesystem translates a virtual block, udf_get_pblock_virt15() may index beyond the inline inode data and read kernel memory outside the intended buffer. Depending on kernel configuration, memory layout, and execution path, the result can be a kernel oops/panic, system denial of service, or exposure of kernel memory contents.

How to fix it

Upgrade to a Linux kernel build that includes the upstream UDF fix validating the VAT header length against the VAT inode size and rejecting VATs that do not leave room for at least one entry. Because no product-specific fixed versions were provided, use your Linux distribution vendor advisories and kernel changelogs to identify the first fixed package for your supported release. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystems, disabling or blocking the UDF filesystem module where it is not required, mounting removable media and disk images only inside isolated/sacrificial environments, and avoiding automated kernel-level mounting of user-supplied UDF/ISO images. Prefer user-space parsing tools or sandboxed workers for untrusted images. Enforce least privilege for mount helpers and remove unnecessary CAP_SYS_ADMIN exposure from containers and services.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is at or above the vendor-fixed version for the affected distribution and that the source or vendor patch includes validation of the VAT 2.0 header length before using it as the virtual partition start offset. Check that the running kernel, not only the installed package, has been updated by validating uname/kernel package metadata after reboot. If UDF support is intentionally disabled as a mitigation, confirm that the udf module is not loaded, cannot be autoloaded by unprivileged workflows, and that mount attempts for UDF filesystems fail in expected contexts. In a controlled non-production test system, exposure can be validated by attempting to mount a known malformed UDF VAT image: vulnerable kernels may produce a kernel oops, KASAN out-of-bounds read, or crash, while fixed kernels should reject the malformed filesystem cleanly.

Typical attack path

1. Craft a UDF filesystem image with a VAT 2.0 virtual partition and an oversized lengthHeader value.
2. Deliver the image to a vulnerable Linux system through removable media, an archive/ISO upload, a disk-image processing workflow, or a local user account.
3. Cause the system to mount or inspect the crafted UDF image with the kernel UDF filesystem driver.
4. Trigger access to virtual partition metadata so the kernel calculates an underflowed VAT entry count.
5. Force virtual block translation on the malformed filesystem, causing an out-of-bounds read in UDF VAT handling.
6. Use the resulting behavior to crash the system or potentially disclose kernel memory, depending on exploit reliability and surrounding controls.

How to detect it

Look for evidence that a vulnerable system mounted or attempted to mount a crafted UDF filesystem before a kernel crash or memory-safety alert. Relevant sources include kernel logs, systemd journal, auditd mount records, EDR telemetry, removable-media events, image-processing service logs, hypervisor/worker logs for automated mounting pipelines, and crash dump/oops reports. Search for UDF mount activity followed by kernel oops, panic, KASAN, UBSAN, page-fault, or general-protection-fault messages referencing UDF code paths, especially udf_load_vat or udf_get_pblock_virt15. Correlate events with recently introduced ISO/UDF images, optical media, removable drives, uploaded disk images, archive extraction jobs, or privileged mount-helper activity. Preserve suspicious images or media for offline analysis and avoid remounting them on production systems. Because there are no unique network indicators and no known campaign-specific artifacts in the provided data, detection is primarily host-forensic and log-correlation based rather than IOC-driven.

• udf_get_pblock_virt15
• udf_load_vat
• KASAN: out-of-bounds in udf_get_pblock_virt15
• KASAN: slab-out-of-bounds in udf_get_pblock_virt15
• KASAN: global-out-of-bounds in udf_get_pblock_virt15
• UDF-fs

What your security team should do

• Prioritize patching Linux systems that mount removable media, process ISO/UDF/disk images, run forensic or backup tooling, or allow local users to mount filesystems.
• Inventory systems with UDF filesystem support enabled, especially servers or containers where untrusted users or workloads may have mount-related privileges.
• Restrict mounting of untrusted filesystems to isolated environments and remove unnecessary CAP_SYS_ADMIN privileges from containers and services.
• Disable or blacklist the udf kernel module on systems that do not require UDF media support, after validating operational impact.
• Monitor kernel logs for UDF-related oops, KASAN, panic, or page-fault messages, especially following mount activity or processing of ISO/removable-media content.
• Review recent mount events, removable-media insertions, and image-processing jobs for unexpected UDF usage.
• Track distribution advisories for the exact fixed kernel versions and ensure reboot completion after kernel updates.
• Treat crashes tied to UDF parsing as potentially malicious until the source image or media has been preserved and analyzed.