HOL LogoGuard

Explore HOL

  • HOL home
  • AI agent registry
  • AI plugins
  • Open standards
  • HOL members
  • Sponsor HOL
  • Advertise with HOL

Guard product

  • Guard overviewLocal security and control for AI agents and the tools they use.
  • FeaturesRuntime protection, policy routing, review, and evidence.

Explore Guard

  • Product previewWalk through Guard surfaces in read-only demo mode.
  • ComparisonCompare Guard with native controls and AI security vendors.

AI tools

  • All AI toolsEvery supported AI tool and how Guard applies policy to it.
  • Codex
  • Claude Code
  • Cursor
  • Antigravity CLI
  • OpenCode
  • Hermes
  • OpenClaw
  • GitHub Copilot CLI
  • Antigravity
  • Kimi
  • Grok
  • Pi / Oh My Pi
  • Zcode

Extensions

  • All extensionsBrowse command and MCP coverage with owners and stated limits.
  • Command coverageShell command protection across clouds, databases, backups, and packages.
  • MCP server coverageSee how Guard maps risk state across MCP tools and servers.
  • Core safetyThe safety floor listings that ship with Guard.
  • Data and resilienceBackup and storage command protection.
  • Cloud and infrastructureAWS, Azure, GCP, Kubernetes, and more.

Security

  • AI security hubSecurity research, advisories, and agent safety coverage.
  • AI tool securitySecurity profiles for each supported coding agent.
  • Safe labsHands-on attack simulations with safe boundaries.
  • Redacted warningsReal blocked actions with sensitive details removed.
  • AdvisoriesCoordinated disclosure reports for AI tooling.
  • Active CVEsSearch active CVEs affecting AI tooling.

Learn

  • Security guidesPractical guides for securing AI agent workflows.
  • DocsInstall, configure, and operate Guard with confidence.
  • ResearchPublished security research, benchmarks, and methodology.

Community

  • ReleasesVersion history, shipped changes and upgrade notes.
  • ContributorsThe people and contributions behind HOL Guard.
  • AffiliatesShare Guard with your audience and earn from referrals.
  • SponsorFund agreed research, implementation and shared testing through the HOL Partner Program.
  • AdvertiseCompare README logo placements, previews and monthly prices, or promote a plugin or extension.
PricingEnterpriseOpen AppInstall Guard
  1. Guard
  2. Security
  3. CVEs
  4. CVE 2024 57976 btrfs do proper folio cleanup when cowfilerange
HOL Guard

Public security guidance for teams protecting AI harnesses, MCP servers, skills, prompts, and local tool execution.

Install Guard

AI Security

  • Prompt injection
  • MCP security
  • OWASP MCP mapping
  • Supply chain

Resources

  • Trust packet
  • Harness setup
  • Redacted warnings
  • Safe labs

Product

  • Install Guard
  • Pricing
  • Open dashboard
Guard
  • Guard Overview
  • Releases
  • Contributors
  • Install Guard
  • Pricing
Docs
  • Documentation Index
  • Developer Hub
  • API Reference
  • Root OpenAPI
  • Registry OpenAPI
  • Run in Postman
  • Standards
  • Submit ERC-8004 Contract
  • Feature Your Agent
Best Plugins
  • Browse Plugins
  • Plugin Launches
  • Best Claude Plugins
  • Best Codex Plugins
  • Best Grok Plugins
  • Best Kimi Plugins
  • Best DeepSeek Plugins
  • Best Antigravity Plugins
  • Best MCP Servers
  • Best Cursor Plugins
  • Best OpenCode Plugins
Best Agents
  • Best ERC-8004 Agents
  • Best Virtuals Agents
  • Best MCP Servers
  • Best A2A Agents
  • Best x402 Payable
  • All Categories
Community
  • Contribute to HOL
  • Telegram
  • X
More
  • About HOL
  • Sponsor
  • Advertise
  • Affiliate program
  • Contact
  • Blog
  • GitHub
  • Privacy
  • Terms of Service
Settings

Copyright ยฉ 2026 HOL DAO LLC. All rights reserved.

Back to active CVEs
High ยท CVSS 7.8CVE-2024-57976

btrfs: do proper folio cleanup when cow_file_range() failedCVE-2024-57976

Answer in brief

CVE-2024-57976 records a High severity (CVSS 7.8) vulnerability in btrfs: do proper folio cleanup when cow_file_range() failed. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Feb 27, 2025Updated Oct 30, 2026Source checked Nov 5, 2026First seen by HOL Aug 5, 2026Material review Oct 30, 2026
Upstream Advisory

Key facts

Risk
High ยท CVSS 7.8
Exploitation
Not marked as known exploited
Affected software
5 mapped packages or products
Fix availability
Available

Why this deserves its current priority

CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Affected products and reported versions
ProductAffected versionsFixed versions
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*Not reportedNot reported
Mapped affected packages and fixed versions
PackageAffected rangeFixed version
Linux/Linuxgeneric2.6.32Not reported
Linux/Linuxgeneric>=8b62b72b26bcd72082c4a69d179dd906bcc22200 <10b3772292bf1be45604ba83fd9650eb94382e78 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <692cf71173bb41395c855acbbbe197d3aedfa5d4 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <06f364284794f149d2abc167c11d556cf20c954b10b3772292bf1be45604ba83fd9650eb94382e78, 692cf71173bb41395c855acbbbe197d3aedfa5d4, 06f364284794f149d2abc167c11d556cf20c954b
Linux/Linuxgeneric>=8b62b72b26bcd72082c4a69d179dd906bcc22200 <4ace6fb49c8be23b005828763d8b0d0bb0f3b0c5 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <10b3772292bf1be45604ba83fd9650eb94382e78 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <692cf71173bb41395c855acbbbe197d3aedfa5d4 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <06f364284794f149d2abc167c11d556cf20c954b4ace6fb49c8be23b005828763d8b0d0bb0f3b0c5, 10b3772292bf1be45604ba83fd9650eb94382e78, 692cf71173bb41395c855acbbbe197d3aedfa5d4, 06f364284794f149d2abc167c11d556cf20c954b
Linux/Linuxgeneric>=8b62b72b26bcd72082c4a69d179dd906bcc22200 <29418ebb8b4d4d090e403d395a6db7e8455331f7 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <4ace6fb49c8be23b005828763d8b0d0bb0f3b0c5 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <10b3772292bf1be45604ba83fd9650eb94382e78 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <692cf71173bb41395c855acbbbe197d3aedfa5d4 || >=8b62b72b26bcd72082c4a69d179dd906bcc22200 <06f364284794f149d2abc167c11d556cf20c954b29418ebb8b4d4d090e403d395a6db7e8455331f7, 4ace6fb49c8be23b005828763d8b0d0bb0f3b0c5, 10b3772292bf1be45604ba83fd9650eb94382e78, 692cf71173bb41395c855acbbbe197d3aedfa5d4, 06f364284794f149d2abc167c11d556cf20c954b

Recommended response

  1. 1Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux, Linux/Linux.
  2. 2Review the reported fix. Update Linux/Linux to 10b3772292bf1be45604ba83fd9650eb94382e78; Linux/Linux to 4ace6fb49c8be23b005828763d8b0d0bb0f3b0c5; Linux/Linux to 29418ebb8b4d4d090e403d395a6db7e8455331f7 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

  1. Published upstream

    Feb 27, 2025

    Evidence: source:cvelist:source_dates:source-dates:record
  2. Source modified

    Oct 30, 2026

    Evidence: source:cvelist:source_dates:source-dates:record
  3. First seen by HOL

    Aug 5, 2026

Sources and claim methodology

  • Source referencegit.kernel.org
  • Source referencegit.kernel.org
  • Source referencegit.kernel.org
  • Source referencegit.kernel.org
  • Source referencegit.kernel.org
Upstream source description

In the Linux kernel, the following vulnerability has been resolved: btrfs: do proper folio cleanup when cow_file_range() failed [BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel. [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished. When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases) ---truncated---

Quoted source text, attributed separately from HOL analysis.

Record context

Vulnerability class
Vulnerability
EPSS
Not reported
CWE IDs
CWE-459
Source
CVE List V5
Source checked
Nov 5, 2026
References
5 linked sources
Open source record