Description

In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF ROOT_REF and ROOT_BACKREF items contain a struct btrfs_root_ref followed by the subvolume name. Several readers assume that this layout is already valid and then use the on-disk name length directly. A corrupted item can therefore make those readers address bytes outside the item, and BTRFS_IOC_GET_SUBVOL_INFO can copy too many bytes into its fixed-size UAPI name buffer. Validate ROOT_REF and ROOT_BACKREF items in tree-checker before any reader uses them. Reject records that do not contain a non-empty name, whose name_len does not exactly describe the remaining item payload, or whose name exceeds BTRFS_NAME_LEN. For BTRFS_IOC_GET_SUBVOL_INFO, copy only the validated on-disk name_len instead of deriving the copy length from the item size. The ioctl result is zeroed when allocated. That leaves the existing trailing zero byte untouched.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-24T17:17:19.223Z",
  "pubdate": "2026-09-24T17:17:19.223Z",
  "executiveSummary": "The Linux kernel Btrfs filesystem driver contains an input validation flaw within the tree-checker component regarding ROOT_REF and ROOT_BACKREF items. This vulnerability arises from inadequate verification of on-disk structure lengths before memory access operations.\nThe primary impact is potential out-of-bounds memory access and information disclosure via the BTRFS_IOC_GET_SUBVOL_INFO ioctl. An attacker capable of mounting a corrupted Btrfs filesystem or influencing its metadata can trigger these conditions.\nThe vulnerability allows for memory corruption or reading sensitive kernel memory beyond the boundaries of the expected item size. Because Btrfs is a widely used filesystem, this poses a significant risk to systems that process untrusted or potentially malicious filesystem images.\nExploitation requires the ability to supply or modify a Btrfs filesystem image that is subsequently mounted or processed by a vulnerable kernel. Successful exploitation results in system instability or the leakage of kernel memory contents to user-space, undermining the security boundary between the filesystem and the kernel.",
  "technicalDetails": "The vulnerability resides in the Btrfs filesystem's tree-checker mechanism, which is responsible for validating on-disk metadata integrity. Specifically, ROOT_REF and ROOT_BACKREF items consist of a struct btrfs_root_ref header followed by a variable-length subvolume name string.\nThe kernel's tree-checker historically failed to perform rigorous bounds checking on these structures. Specifically, it did not enforce that the name_len field accurately reflected the remaining payload size within the item, nor did it strictly enforce the BTRFS_NAME_LEN maximum constraint for the subvolume name. Furthermore, the implementation allowed for empty name fields, which can lead to logical errors in downstream filesystem operations.\nThe exploitation flow begins with the creation or modification of a malicious Btrfs filesystem image. An attacker crafts metadata blocks where the length field defined in the ROOT_REF or ROOT_BACKREF entry is intentionally mismatched with the actual item size or exceeds the allocated capacity of the destination buffer used by kernel-space readers. When the kernel reads these corrupted items, the lack of validation causes downstream functions to treat the on-disk length as authoritative, resulting in read operations that extend past the bounds of the valid item payload.\nA critical vector is the BTRFS_IOC_GET_SUBVOL_INFO ioctl. This interface retrieves subvolume information and copies the subvolume name into a fixed-size UAPI buffer. Because the length of this copy operation was historically derived directly from the item size rather than a validated on-disk length, a corrupted filesystem can induce an out-of-bounds copy. This results in the leakage of adjacent kernel heap memory into the user-provided buffer, effectively exposing sensitive kernel data to unprivileged users.\nTo address this, the implementation has been updated to enforce strict validation within the tree-checker. The checker now verifies that the name field is non-empty, the name_len matches the remaining payload size exactly, and the total length does not exceed BTRFS_NAME_LEN. Additionally, the BTRFS_IOC_GET_SUBVOL_INFO implementation now uses the validated length rather than the item size for copy operations, ensuring that the kernel-to-user memory transition remains within the intended boundaries."
}