Linux Kernel up to 6.8.7 btrfs_clear_buffer_dirty allocation of resources

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.8.7. It has been rated as problematic. This affects the function btrfs_clear_buffer_dirty. Performing a manipulation results in allocation of resources. This vulnerability is reported as CVE-2024-36027. No exploit exists. Upgrading the affected component is advised.

Detailsinfo

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.8.7. This affects the function btrfs_clear_buffer_dirty. The manipulation with an unknown input leads to a allocation of resources vulnerability. CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. The impact remains unknown. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer Btrfs clears the content of an extent buffer marked as EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is introduced to prevent a write hole of an extent buffer, which is once allocated, marked dirty, but turns out unnecessary and cleaned up within one transaction operation. Currently, btrfs_clear_buffer_dirty() marks the extent buffer as EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call happens while the buffer is under IO (with the WRITEBACK flag set, without the DIRTY flag), we can add the ZEROOUT flag and clear the buffer's content just before a bio submission. As a result: 1) it can lead to adding faulty delayed reference item which leads to a FS corrupted (EUCLEAN) error, and 2) it writes out cleared tree node on disk The former issue is previously discussed in [1]. The corruption happens when it runs a delayed reference update. So, on-disk data is safe. [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/ The latter one can reach on-disk data. But, as that node is already processed by btrfs_clear_buffer_dirty(), that will be invalidated in the next transaction commit anyway. So, the chance of hitting the corruption is relatively small. Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to keep the content under IO intact.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2024-36027 since 05/17/2024. Technical details are known, but no exploit is available.

Upgrading to version 6.8.8 eliminates this vulnerability. Applying the patch f4b994fccbb6/68879386180c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2024-1259). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• IBM InfoSphere Guardium
• Oracle Linux
• Oracle VM
• NetApp FAS
• EMC Avamar
• NetApp AFF
• Dell NetWorker
• NetApp ActiveIQ Unified Manager
• IBM Security Guardium
• RESF Rocky Linux
• Broadcom Brocade SANnav
• Open Source Linux Kernel
• IBM Business Automation Workflow
• IBM QRadar SIEM
• Dell Avamar
• IBM Storage Scale
• IBM Spectrum Protect Plus
• Juniper Junos Space
• IBM Storage Scale System
• SolarWinds Security Event Manager

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.8.0
• 6.8.1
• 6.8.2
• 6.8.3
• 6.8.4
• 6.8.5
• 6.8.6
• 6.8.7

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion