CVE-2026-64324

What it actually does

This is a Linux kernel UDF filesystem bounds-checking flaw in free-space accounting. When udf_free_blocks() validates a free-block extent, it checks the logical block number and count against the partition length but fails to include the extent offset in the final boundary calculation. A crafted UDF filesystem can therefore cause logicalBlockNum + offset + count to exceed the partition while still passing validation, leading later code to index past the space bitmap array. The reported, reproducible outcome is an out-of-bounds bitmap pointer access followed by a kernel panic. The practical impact described for the flaw is local denial of service; no reliable confidentiality or integrity impact is claimed by the vulnerability description despite the high CVSS vector components.

Why it matters to the business

An attacker with local access can crash affected Linux systems by using a specially crafted UDF filesystem image or removable medium and triggering file truncation on it. On desktops and workstations where active users can mount removable media through UDisks/polkit without administrator privileges, this can be exploited by a regular user and may cause sudden workstation outages, loss of unsaved work, and help-desk disruption. On servers or hardened systems where mounting filesystems requires root or CAP_SYS_ADMIN, the attack requires higher privileges or an existing foothold. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, local crash reliability makes it relevant for multi-user Linux systems, kiosks, lab machines, VDI, and environments allowing removable media.

How an attack unfolds

An attacker prepares a malformed UDF filesystem whose free block extent metadata contains a logical block number, count, and extent offset combination that passes the incomplete partition-length check but resolves beyond the actual partition boundary. The attacker then gets the affected Linux host to mount the crafted UDF media or image. On permissive desktop configurations, this may be possible as an active unprivileged user through automount or user-initiated mounting mediated by UDisks and polkit. Once mounted writable, the attacker performs a single ftruncate(2) operation on a file backed by the malicious extent. During the truncation path, the kernel calls UDF free-block handling routines, indexes beyond the expected space bitmap array, and panics. The attack does not require network access and is primarily a local availability attack.

How to fix it

Apply vendor kernel updates that include the UDF fixes for validating free block extents against the full partition length and rejecting out-of-range block groups in load_block_bitmap(). Because no exact affected product list or fixed package versions were provided, use the Linux distribution’s security advisories and kernel changelog to identify the corrected kernel build for each supported release. After installing the fixed kernel, reboot into it; live-patching is only sufficient if the vendor explicitly states that this UDF filesystem fix is covered. Where immediate patching is not possible, reduce exposure by disabling automatic mounting of removable media, restricting UDisks/polkit policies so ordinary users cannot mount arbitrary UDF filesystems, blocking or controlling USB/removable media, avoiding mounting untrusted UDF images, and requiring administrative approval for loopback or removable filesystem mounts. On systems that do not need UDF support, consider disabling or blacklisting the UDF kernel module if operationally safe.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that includes the UDF bounds-check fix, not merely that the package is installed. Validate with uname -r, distribution package tooling, and the vendor advisory or changelog. Review whether udf is built into the kernel or available as a loadable module, and confirm whether local policy allows non-administrative users to mount UDF media. For exposure reduction, test that unprivileged users cannot mount arbitrary UDF images or removable UDF filesystems unless required. For fix validation in a controlled lab only, mount a known proof-of-concept malformed UDF image against an updated non-production kernel and verify that the filesystem is rejected or the operation fails safely without a kernel panic. Do not perform crash-triggering validation on production systems.

Typical attack path

1. Obtain local access to an affected Linux system or convince/enable a local user session to handle attacker-controlled UDF media.
2. Create or supply a crafted UDF filesystem image or removable device with malformed free block extent metadata.
3. Mount the crafted UDF filesystem; on some desktop systems this may be possible without CAP_SYS_ADMIN through UDisks/polkit policy.
4. Ensure a writable file on the crafted filesystem is associated with the malicious extent layout.
5. Trigger ftruncate(2) against that file.
6. The kernel enters UDF free-block accounting, performs an incomplete bounds check, indexes past the space bitmap array, and panics the system.

How to detect it

Retrospective detection is difficult because successful exploitation results in a kernel panic and may leave only pre-crash or post-reboot evidence. Focus on kernel logs, persistent journald storage, crash dumps, kdump/vmcore data, audit logs, UDisks logs, polkit authorization logs, and endpoint telemetry around the time of unexpected reboots. Look for UDF filesystem mount events shortly before a panic, especially mounts of removable media, loop devices, or user-initiated mounts followed by truncation or file modification activity. Search kernel logs for UDF-related messages, stack traces containing udf_free_blocks(), load_block_bitmap(), or UDF free-space/bitmap handling, and generic panic signatures occurring immediately after UDF mount activity. On desktop systems, correlate org.freedesktop.UDisks2 and polkit events showing a non-administrative active user mounting UDF media. On systems with auditd or EDR, look for mount operations specifying type udf, loop device attachment to ISO/UDF-like images, ftruncate/truncate activity against the mounted path, and abrupt reboot or crash events. Absence of these artifacts does not prove non-exploitation because volatile logs may be lost during panic unless persistent logging or crash capture was enabled.

• UDF-fs
• udf_free_blocks
• load_block_bitmap
• kernel panic
• Kernel panic - not syncing
• BUG: unable to handle kernel
• Oops:
• mount -t udf
• type=udf
• org.freedesktop.UDisks2
• polkitd
• /usr/lib/udisks2/udisksd
• /dev/loop
• /dev/sr0
• /dev/cdrom
• /proc/filesystems
• /sys/module/udf
• truncate
• ftruncate

What your security team should do

• Prioritize patching Linux desktops, shared workstations, VDI hosts, kiosks, and multi-user systems where local users can mount removable media.
• Patch servers during the next appropriate maintenance window unless they allow untrusted local users, removable media, or loop-mounted filesystem images, in which case increase priority.
• Verify that systems rebooted into the fixed kernel after update; stale running kernels remain vulnerable.
• Temporarily restrict UDisks/polkit removable-media mounting for non-administrative users where feasible.
• Disable automount for removable media on sensitive endpoints until patched.
• Block or monitor use of untrusted UDF media and disk images, especially in environments with shared local access.
• Review recent unexplained Linux kernel panics for UDF-related stack traces or mount activity involving removable media.
• If UDF support is not required, evaluate disabling or blacklisting the udf module as a defense-in-depth control.
• Communicate to help-desk and endpoint teams that sudden crashes following removable media use may be security-relevant, not just hardware instability.