CVE-2026-64324 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
udf: validate free block extents against the partition length
udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array.
A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite.
No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic.
Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted
callers cannot walk past the flexible array.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability in question represents a critical kernel memory safety issue within the Linux UDF (Universal Disk Format) filesystem implementation that arises from improper validation of free block extents during partition boundary checks. This flaw exists in the udf_free_blocks() function where the logical block number and count parameters are validated against the partition length, but the extent offset component is inadvertently excluded from this crucial boundary verification. The omission creates a window where maliciously crafted filesystem metadata can bypass the protective bounds check while still causing subsequent memory access violations.
The technical nature of this vulnerability stems from a classic buffer over-read condition that occurs when the kernel calculates the final block address by summing logicalBlockNum + offset + count and then uses this computed value for partition length validation. However, the function fails to properly account for the extent offset in this calculation, allowing an attacker to craft an extent that appears valid during initial checking but actually points beyond the legitimate partition boundaries. When the kernel later processes this invalid extent during bitmap indexing operations, it accesses memory locations beyond the allocated space_bitmap array, resulting in undefined behavior and system instability.
This vulnerability demonstrates a clear violation of the CWE-129 principle regarding improper validation of array indices, specifically manifesting as an out-of-bounds memory access pattern that leads to kernel panic conditions. The operational impact is significant as it represents a local privilege escalation vector with availability implications, where unprivileged users can trigger system crashes through carefully constructed filesystem metadata. The attack scenario involves a single ftruncate(2) system call on files backed by maliciously crafted extents, making the exploitation both simple and reliable.
The threat landscape for this vulnerability extends beyond traditional security boundaries as it affects desktop systems where UDisks and polkit configurations allow regular users to mount removable UDF media without requiring administrative privileges. This creates a scenario where any local user can potentially craft a malicious filesystem image and trigger the kernel panic by simply truncating a writable file on that media, effectively creating an unprivileged denial-of-service attack vector against desktop systems. The vulnerability's exploitability is further enhanced by the fact that it requires no special permissions beyond normal file system access rights, making it particularly dangerous in multi-user environments.
The mitigation strategy involves implementing proper bounds checking by utilizing the already computed logicalBlockNum + offset + count value for partition length validation as recommended in the fix. Additionally, the load_block_bitmap() function must be enhanced to reject out-of-range block groups before attempting to index into the s_block_bitmap[] array, thereby preventing corrupted callers from walking past the flexible array boundaries. This remediation approach aligns with established security practices that emphasize defensive programming techniques and early input validation to prevent memory corruption vulnerabilities. The solution effectively addresses both the immediate memory safety issue and prevents potential escalation paths that could arise from similar boundary checking flaws in related filesystem operations, thereby strengthening the overall kernel security posture against local privilege escalation attacks.