LiveActive security incident?Get immediate response
CVE Record

CVE-2025-39779: btrfs: subpage: keep TOWRITE tag until folio is cleaned

In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: <TASK> ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.

HighCVSS 7.8Not KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysishigh

Security readout for executives and security teams

Plain-English summary

A Linux Btrfs writeback race can break required disk-write ordering. Under affected configurations, one process may finish without waiting for partially dirty data, potentially causing a kernel crash or threatening data integrity when files are truncated. The supplied CVSS score is 7.8, but exploitation requires local, low-privileged access.

Executive priority

Prioritize systems where Btrfs protects important data, especially zoned storage or compressed-write environments. Schedule a vendor-supported kernel update promptly because failure may affect availability and data integrity. Broader emergency action is not supported by the supplied evidence because the issue is local and no active exploitation is documented.

Technical view

Btrfs subpage writeback prematurely clears PAGECACHE_TAG_TOWRITE while blocks in a folio remain dirty. A concurrent WB_SYNC_ALL operation can then miss that folio and return without waiting, violating writeback ordering. Zoned or compressed writes are highlighted. The fix retains TOWRITE until the folio is clean, then clears it explicitly.

Likely exposure

Exposure is limited to affected Linux kernels using Btrfs paths involving subpage writeback. Zoned setups and compressed-write workloads are specifically implicated. The supplied version data lists affected releases including 5.13, 6.12.44, 6.16.4, and 6.17, but its range semantics are incomplete; confirm exposure against distribution guidance and referenced fixes.

Exploitation context

The provided sources contain no evidence of active exploitation, and the bundle marks the CVE as absent from KEV. The demonstrated outcome is a reproducible kernel assertion and crash during filesystem testing. The CVSS vector describes a local, low-privileged attack path without user interaction; no remote vector is identified.

Researcher notes

The failure is a writeback-ordering race between WB_SYNC_NONE and WB_SYNC_ALL over a partially dirty folio. Premature TOWRITE removal makes the synchronous collector miss outstanding work. The source bundle provides three stable-kernel fixes but ambiguous affected-version boundaries and no CWE classification. Validate branch-specific ancestry through the distribution's kernel package metadata.

Mitigation direction

  • Inventory Linux hosts using Btrfs, prioritizing zoned devices, subpage configurations, and compressed-write workloads.
  • Update to a vendor-supported kernel containing the applicable referenced stable fix.
  • Before updating, protect critical data with tested backups and follow vendor maintenance guidance.
  • If immediate updating is impossible, consult the distribution vendor for supported mitigations; none are documented in the bundle.

Validation and detection

  • Record each host's kernel build, distribution package revision, Btrfs usage, mount configuration, and storage type.
  • Map the installed kernel to vendor advisories or the applicable referenced stable commit.
  • After updating, confirm the running kernel includes the fix and reboot completion where required.
  • Monitor affected hosts for Btrfs assertions, kernel BUG events, writeback errors, and unexpected restarts.
Prepared
Confidence
high
Sources
5

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-39779 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
High
CVSS
7.8 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

1CVSS vectors
3Timeline events
0ADP providers
4Source links

CVSS vector scores

1 official score

We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.

ScoreVersionSeverityVectorExploitImpactSource
7.8CVSS 3.1HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H1.85.9Linux

Vulnerability scoring details

Base CVSS 3.1 score

7.8High
CVSS 3.1 vector shape for CVE-2025-39779Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux3470da3b7d87fde4b9729d4e29c2dc074cd59c10, 3470da3b7d87fde4b9729d4e29c2dc074cd59c10, 3470da3b7d87fde4b9729d4e29c2dc074cd59c10unaffected
LinuxLinux5.13, 0, 6.12.44, 6.16.4, 6.17affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.