CVE-2021-47189: btrfs: fix memory ordering between normal and ordered work functions
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory ordering between normal and ordered work functions
Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20
<registers omitted for brevity>
Call trace:
submit_compressed_extents+0x38/0x3d0
async_cow_submit+0x50/0xd0
run_ordered_work+0xc8/0x280
btrfs_work_helper+0x98/0x250
process_one_work+0x1f0/0x4ac
worker_thread+0x188/0x504
kthread+0x110/0x114
ret_from_fork+0x10/0x18
Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.
Security readout for executives and security teams
Plain-English summary
CVE-2021-47189 is a Linux kernel Btrfs bug where worker threads can see stale or inconsistent state. The source describes crashes, especially on ARM64, rather than a proven widespread compromise path. Business urgency is moderate for systems using affected kernels and Btrfs.
Executive priority
Handle through normal kernel patch governance, with higher priority for production systems using Btrfs or ARM64. There is no source-backed evidence of active exploitation, but kernel crashes can affect service reliability.
Technical view
The issue is missing memory ordering around Btrfs normal and ordered work functions. WORK_DONE_BIT was used for synchronization without ordering guarantees, allowing fields such as async_chunk::inode to appear inconsistent and leading to crashes in submit_compressed_extents. Stable kernel commits add write and read barriers.
Likely exposure
Exposure is most plausible on Linux systems running affected kernel versions with Btrfs workloads. The source highlights ARM64 crash manifestation and Btrfs compressed extent handling. Distribution exposure requires checking whether vendor kernels include the referenced stable fixes.
Exploitation context
The provided bundle marks KEV as false and does not cite active exploitation. The public description documents crash behavior from a concurrency ordering flaw. Do not treat this as exploited unless later vendor, KEV, or incident sources support that.
Researcher notes
The affected logic relies on WORK_DONE_BIT between normal_func and ordered_func execution. The fix orders accesses before setting the bit and after reading it, preventing ordered_func from observing pre-flag state inconsistently. Affected range evidence is source-bundle limited.
Mitigation direction
Apply vendor kernel updates containing the referenced Linux stable fixes.
Prioritize hosts using Btrfs on affected kernel branches.
Check distribution advisories before applying custom kernel changes.
Schedule reboot or live-patching according to vendor-supported process.
Monitor for recurring Btrfs crash traces until patched.
Validation and detection
Inventory Linux kernel versions across affected assets.
Identify systems using Btrfs filesystems or Btrfs compression paths.
Map installed kernels to vendor fixes or referenced stable commits.
Review crash logs for submit_compressed_extents or async_cow_submit traces.
Confirm patched systems are running the updated kernel after maintenance.
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-2021-47189 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.
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.