Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2024-36027btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer

Description

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.

Timeline

  1. ID reserved

    By Linux

  2. · 13 days later

    Published

  3. · 2 years later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2024-36027, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1High7.1CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
NVDNVD · Modified3.1High7.1CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
EPSS (exploitation in 30 days)
0.21% · top 88% of all CVEs (14 Nov 2026)
CISA SSVC
Exploitation: none · Automatable: no · Technical impact: partial
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.1.

Affected products

  • Linux · Linux

    • affected aa6313e6ff2bfbf736a2739047bba355d8241584 – < f4b994fccbb6f294c4b31a6ca0114b09f7245043
    • affected aa6313e6ff2bfbf736a2739047bba355d8241584 – < 68879386180c0efd5a11e800b0525a01068c9457

  • Linux · Linux

    • affected 6.8
    • unaffected < 6.8
    • unaffected 6.8.8 – ≤ 6.8.*
    • unaffected 6.9 – ≤ *

References

References2

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2024-36027 badge
[![CVE-2024-36027](https://cveledger.app/badge/CVE-2024-36027.svg)](https://cveledger.app/cve/CVE-2024-36027)

Record last updated .