CVE-2026-64322

What it actually does

CVE-2026-64322 is a Linux kernel memory-corruption flaw in the UDF filesystem driver. The vulnerable code validates the UDF sparing table length as if it were a byte count, but later uses the same value as a count of 8-byte sparingEntry structures. A crafted UDF filesystem image can therefore cause the kernel to read beyond the allocated block in udf_get_pblock_spar15() and, in relocation paths, perform out-of-bounds reads during CRC calculation and out-of-bounds writes through memmove() in udf_relocate_blocks(). Practical outcomes include kernel crash, memory disclosure, corruption of kernel memory, and potentially local privilege escalation depending on kernel configuration, exploit reliability, and available hardening.

Why it matters to the business

Systems that allow users or services to mount untrusted UDF media or disk images may be exposed to local denial of service or potential privilege escalation. This is most relevant to Linux endpoints, servers, virtualization hosts, forensic workstations, file-processing services, container/VM image handling pipelines, and environments where removable media or optical/ISO-style images are automatically mounted. The EPSS score is currently low and it is not listed in CISA KEV, but the issue affects kernel-level code, so successful exploitation can have severe operational consequences including host crashes and possible full host compromise.

How an attack unfolds

An attacker prepares a malformed UDF filesystem image with a sparing table whose reallocationTableLen value passes the vulnerable block-size validation but is large enough to make later code walk beyond the actual table. The attacker then needs the target Linux system to process or mount that image, for example through local access, removable media, a submitted disk image, an archive or ISO-processing workflow, or an automated mount service. Once the UDF driver parses the crafted sparing table, kernel code indexes past the intended buffer. Read paths may disclose or dereference out-of-bounds kernel memory and cause a crash; relocation/update paths may calculate a CRC over memory past the block and perform an out-of-bounds write. If the attacker can shape memory layout and reach the write path reliably, the bug may be developed into privilege escalation; otherwise the most likely observable impact is a kernel oops, panic, or filesystem-related crash.

How to fix it

Apply the Linux kernel update that fixes UDF sparing table validation by validating reallocationTableLen as an entry count using the full sparingEntry structure size rather than as a byte count. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor once available. Prioritize systems that mount removable media, process user-supplied disk images, run desktop automount services, support ISO/UDF ingestion, or expose image-mounting functionality to less-trusted users. If immediate patching is not possible, reduce exposure by disabling or restricting UDF filesystem mounting, disabling desktop/server automount features, blocking untrusted removable media, preventing unprivileged users from mounting filesystem images, and processing untrusted disk images only in isolated sandboxed VMs that can be discarded after use.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the UDF sparing table length validation issue, not merely that a package has been installed. Validate by checking the running kernel version against the distribution advisory, confirming reboot into the fixed kernel, and reviewing vendor changelogs for the UDF fix. Where source verification is possible, confirm udf_load_sparable_map() validates reallocationTableLen using the size of struct sparingEntry entries, such as with struct_size(), rather than adding the raw value directly as bytes. To check exposure, identify systems where the udf filesystem is available and where UDF images can be mounted by users, services, automounters, or image-processing workflows. After remediation, test that normal UDF media still mounts and that a malformed test image is rejected without kernel warnings, oopses, or crashes.

Typical attack path

1. Attacker obtains local execution, local media access, or a path to submit a filesystem image that the target will mount or inspect.
2. Attacker crafts a UDF image with a malformed sparing table where reallocationTableLen is valid under the vulnerable byte-count check but invalid as an entry count.
3. The image is mounted or parsed by a vulnerable Linux kernel using the UDF filesystem driver.
4. The kernel accepts the malformed sparing table and later treats reallocationTableLen as the number of sparingEntry records.
5. UDF code reads beyond the table in udf_get_pblock_spar15() and may reach relocation/update logic that performs out-of-bounds reads and writes.
6. The system may crash, leak kernel memory, corrupt kernel memory, or potentially allow the attacker to elevate privileges.

How to detect it

Look for evidence that untrusted or unexpected UDF filesystems were mounted shortly before kernel crashes, oopses, or memory-corruption alerts. Useful sources include kernel logs from journalctl -k, /var/log/kern.log, /var/log/messages, auditd logs, udisks/automount logs, EDR process telemetry, shell history for mount/udisks commands, and crash dump systems such as kdump, apport, ABRT, or systemd-coredump metadata. Investigate kernel messages referencing UDF parsing, sparing tables, udf_get_pblock_spar15(), udf_relocate_blocks(), udf_update_tag(), crc_itu_t(), slab-out-of-bounds, out-of-bounds, general protection faults, page faults, kernel BUG/Oops, or KASAN reports. Correlate these with recent insertion of removable media, loop-device setup, mount operations using -t udf, losetup activity, udisksctl mount activity, or services ingesting ISO/UDF images. Preserve suspicious UDF images and loop-device backing files for forensic analysis. Absence of these logs does not prove non-exploitation because successful exploitation may leave only generic kernel instability or may erase volatile evidence after a crash.

• UDF-fs:
• mount -t udf
• type=udf
• udisksctl mount
• losetup
• /dev/loop
• udf_get_pblock_spar15
• udf_relocate_blocks
• udf_update_tag
• crc_itu_t
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• RIP: udf_get_pblock_spar15
• RIP: udf_relocate_blocks
• RIP: udf_update_tag
• RIP: crc_itu_t

What your security team should do

• Inventory Linux systems that support or mount UDF filesystems, especially endpoints, file-ingestion systems, forensic tools, virtualization/image-processing hosts, and systems with removable media access.
• Patch affected Linux kernels using vendor-supplied updates and ensure systems reboot into the fixed kernel.
• Temporarily disable or restrict UDF mounting where it is not business-critical, particularly for untrusted users and automated workflows.
• Disable automount for removable media and disk images on high-risk systems until patched.
• Review sudoers, polkit, udisks, container, and image-processing workflows for paths that let low-privileged users trigger kernel filesystem mounts.
• Treat unexplained kernel crashes involving UDF code as potentially security-relevant and preserve logs, crash dumps, and any mounted images for analysis.
• Monitor distribution security advisories for exact fixed kernel package versions and backports, since fixed versions were not provided in the input.
• Because the issue is not currently in KEV and EPSS is low, prioritize based on exposure to untrusted filesystem images rather than internet-facing risk.