CVE-2025-40205

Root

Cause

In the Linux kernel's BTRFS filesystem, the btrfs_encode_fh() function does not properly validate the provided buffer size (*max_len) against the actual size required for all three possible file handle types it can produce. The function initially returns to the caller sizes such as BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords). However, when a parent inode exists and the root IDs differ, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes) without checking that the buffer is large enough. This results in an 8-byte out-of-bounds write to fid->parent_root_objectid [1].

Exploitation

To trigger the bug, an attacker would need to invoke an operation that encodes a file handle for a BTRFS inode where a parent exists and the parent's root ID differs from the inode's root ID. The file handle's *max_len must be set to a value smaller than 40 bytes but larger than or equal to 32 bytes. While the issue is considered not easily triggerable in typical usage, it can be provoked by a specially crafted system call or a container escape scenario that passes a small buffer to the fh argument. The primary risk arises when the kernel writes beyond the intended buffer, leading to memory corruption [1].

Impact

An out-of-bounds write can corrupt adjacent kernel slab memory, potentially causing a system crash (denial of service) or, in more sophisticated attacks, allowing an escalation of privileges. Because the write occurs within a kernel function that is reachable from user space via system calls like name_to_handle_at(), a local attacker may exploit this to overwrite sensitive kernel structures. The exact exploitability depends on memory layout and mitigations such as KASLR, but the vulnerability is classified as a potential memory corruption bug [1].

Mitigation

The fix, applied in the upstream Linux kernel, ensures that btrfs_encode_fh() returns the correct size for all three handled cases and validates that *max_len is sufficiently large before writing any data. Users should update their kernel to include commits 43143776b0a7, 0276c8582488, d3a9a8e1275e, or 361d67276eb8 [1][2][3][4]. There is no known workaround other than applying the patch, as the vulnerability stems from incomplete bounds checking in core filesystem code.