CVE-2026-64324: udf: validate free block extents against the partition length
In the Linux kernel, the following vulnerability has been resolved:
udf: validate free block extents against the partition length
udffreeblocks() 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 CAPSYSADMIN, 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 CAPSYSADMIN 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 loadblockbitmap() reject an out-of-range block group before indexing sblockbitmap[], so corrupted callers cannot walk past the flexible array.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.145.2-1 - Configuration
Update/patch the Linux kernel so that UDF free block extents are validated against the partition length, and ensure load_block_bitmap() rejects out-of-range extents before indexing s_block_bitmap[] (prevent callers from walking past the flexible array and avoid truncation-triggered panic).
Linux kernel UDF filesystem udf_free_blocks()/load_block_bitmap() bounds validation = Ensure validation prevents out-of-bounds bitmap pointer access and prevents kernel panic
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems that mount writable UDF filesystems are exposed. Desktop systems that allow an active user to mount removable UDF media through UDisks/polkit without CAP_SYS_ADMIN have a lower attack barrier; systems requiring root or CAP_SYS_ADMIN to mount the image have a higher prerequisite.
What does an attacker need to trigger the vulnerability?
An attacker needs to provide a crafted UDF filesystem containing a malformed free-block extent, have it mounted writable, and perform ftruncate(2) on a file backed by that extent. The documented result is a reliable kernel panic.
What is the security impact?
This is a local availability issue resulting in denial of service through a kernel panic. The reported primitive is an out-of-bounds read of a bitmap pointer slot; no confidentiality or integrity impact is claimed.
What can be done if patching is not immediately possible?
Restrict unprivileged users from mounting removable or attacker-supplied UDF media, particularly through desktop mounting mechanisms that do not require CAP_SYS_ADMIN. Requiring root or CAP_SYS_ADMIN to mount such images raises the exploitation prerequisite.