CVE-2024-35949 is a vulnerability in the Linux kernel's Btrfs filesystem implementation related to metadata integrity checking. Btrfs uses metadata blocks to manage filesystem structures, and the kernel relies on a WRITTEN flag to indicate that these blocks have been properly written and validated. The vulnerability arises because the kernel's integrity checking code previously only performed extended leaf checks on metadata blocks if the WRITTEN flag was set. However, due to changes in the kernel code (notably the removal of the CONFIG_BTRFS_FS_CHECK_INTEGRITY option), the function btrfs_check_leaf() is only called on blocks being written out or read in, which should have the WRITTEN flag set. This creates a gap where corrupted filesystem images with manipulated WRITTEN bits can bypass these integrity checks. Specifically, if the WRITTEN bit is not set on some leaf blocks, the extended leaf checks that validate item pointers (to prevent out-of-bounds memory access) are skipped. An attacker can craft a malicious Btrfs image that tweaks the WRITTEN bit to cause out-of-bounds memory access, leading to potential kernel crashes (general protection faults) or memory corruption. The vulnerability was discovered through KASAN (Kernel Address Sanitizer) reports indicating wild memory accesses and general protection faults during mount operations on a crafted image. The issue affects Linux kernel versions including commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and was addressed by adding checks to ensure the WRITTEN flag is set appropriately and that __btrfs_check_leaf() always performs item pointer validation regardless of the WRITTEN flag state. This fix protects against corrupted filesystems that could otherwise bypass critical integrity checks, preventing potential exploitation scenarios such as kernel memory corruption or denial of service.

For European organizations, this vulnerability poses a significant risk primarily to systems running Linux with Btrfs filesystems, especially those that mount untrusted or externally sourced Btrfs images. The impact includes potential kernel crashes leading to denial of service, and possibly memory corruption that could be leveraged for privilege escalation or arbitrary code execution, although no known exploits are reported in the wild yet. Organizations relying on Btrfs for critical storage, such as cloud providers, hosting services, or enterprises using Linux-based infrastructure, could face system instability or data integrity issues if exposed to crafted malicious images. The vulnerability could be exploited by attackers who can supply or manipulate Btrfs images, for example via compromised storage media, network shares, or container images. This risk is heightened in environments where Linux systems are used for virtualization, containerization, or as file servers. The lack of a CVSS score and no known exploits suggest the threat is not yet widespread, but the potential for kernel-level memory corruption makes it a high-risk vulnerability requiring prompt attention.

European organizations should immediately update their Linux kernels to versions that include the patch for CVE-2024-35949. Since the vulnerability involves the Btrfs filesystem, organizations should audit their use of Btrfs, especially in environments where untrusted Btrfs images or snapshots are mounted. Specific mitigation steps include: 1) Apply the latest Linux kernel updates from trusted vendors that address this vulnerability. 2) Avoid mounting untrusted or unauthenticated Btrfs images or snapshots. 3) Implement strict access controls and integrity verification on storage media and images to prevent tampering with the WRITTEN flag or other metadata. 4) Use kernel hardening features such as KASAN and other memory protection mechanisms in testing environments to detect similar issues proactively. 5) For environments using containerization or virtualization, ensure base images and snapshots are verified and updated. 6) Monitor kernel logs for Btrfs warnings or errors indicative of corruption or exploitation attempts. 7) Consider fallback to more mature filesystems if Btrfs is not essential, until the environment is fully patched and tested. These steps go beyond generic advice by focusing on controlling the source and integrity of Btrfs images and ensuring kernel updates are applied promptly.