CVE-2026-64361: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length
In the Linux kernel, the following vulnerability has been resolved:
hfs/hfsplus: fix u32 overflow in checkandcorrectrequestedlength
checkandcorrectrequestedlength() compares (off + len) against nodesize using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfsbrecremove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail.
For example, with off=14 and len=0xFFFFFFF2 (underflowed from dataoff - keyoffset - size in hfsbrecremove), off + len wraps to 6, which is less than a typical nodesize of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer.
Fix this by widening the addition to u64 before comparing against nodesize. This prevents the u32 wrap while keeping the logic straightforward.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update hfs/hfsplus so check_and_correct_requested_length() widens the addition to u64 before comparing (off + len) against the limit, preventing u32 wrap/underflow scenarios where off + len would overflow to a small value and allow an out-of-bounds memmove.
Linux kernel (hfs/hfsplus) check_and_correct_requested_length() bounds check arithmetic = Use u64 for (off + len) comparison instead of u32
Event History
Peer vulnerabilities
Found alongside the following vulnerabilities.
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel's HFS or HFS+ filesystem code are exposed when they process inputs that can reach the affected record-removal path. Exploitation requires local, low-privileged access; no user interaction is required.
What does an attacker need to trigger the flaw?
An attacker needs to cause a large length value, such as one produced by an underflow in hfs_brec_remove(), to be passed to check_and_correct_requested_length(). The 32-bit addition can then wrap and allow a subsequent memmove to read roughly 4 GB beyond the node buffer.
What is the impact if exploitation succeeds?
The vulnerability is rated high with CVSS 7.8 and affects confidentiality, integrity, and availability. The out-of-bounds memory access can result from a bounds check incorrectly accepting a wrapped length.
What change fixes the vulnerable check?
The fix performs the offset-plus-length addition using u64 arithmetic before comparing it with node_size. This prevents the u32 wraparound that allowed the bounds check to pass.