CVE-2022-50293: btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range
If we get -ENOMEM while dropping file extent items in a given range, at
btrfs_drop_extents(), due to failure to allocate memory when attempting to
increment the reference count for an extent or drop the reference count,
we handle it with a BUG_ON(). This is excessive, instead we can simply
abort the transaction and return the error to the caller. In fact most
callers of btrfs_drop_extents(), directly or indirectly, already abort
the transaction if btrfs_drop_extents() returns any error.
Also, we already have error paths at btrfs_drop_extents() that may return
-ENOMEM and in those cases we abort the transaction, like for example
anything that changes the b+tree may return -ENOMEM due to a failure to
allocate a new extent buffer when COWing an existing extent buffer, such
as a call to btrfs_duplicate_item() for example.
So replace the BUG_ON() calls with proper logic to abort the transaction
and return the error.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel Btrfs reliability flaw: an out-of-memory condition in a file-extent cleanup path could hit BUG_ON(), causing an excessive kernel failure instead of returning an error. The business impact is most plausibly availability loss on systems using Btrfs. The source bundle does not provide CVSS, CWE, or active exploitation evidence.
Executive priority
Treat as a targeted availability risk for Btrfs-backed Linux systems. It should be included in normal kernel patch cycles, with faster handling for critical storage or service hosts using Btrfs. No source evidence supports emergency response for active exploitation.
Technical view
The fix changes btrfs_drop_extents() so ENOMEM during extent reference updates aborts the transaction and returns the error, rather than triggering BUG_ON(). The affected surface is Linux kernel Btrfs code handling file extent item removal over a range. Stable kernel commits are referenced as remediation, but distribution backport status must be verified per vendor kernel.
Likely exposure
Exposure is most relevant to Linux systems using Btrfs on affected kernel builds. Systems not using Btrfs are unlikely to exercise this code path. Exact exposure depends on kernel version and whether the relevant stable commits, or vendor backports, are present.
Exploitation context
The bundle does not show CISA KEV listing or any cited active exploitation. The described condition depends on ENOMEM during Btrfs extent dropping, suggesting an availability issue rather than data disclosure or remote code execution. Practical triggerability is not established by the provided sources.
Researcher notes
Key evidence is the upstream description and stable commit references. Missing details include CVSS, CWE, exploitability assessment, and distribution-specific affected ranges. Avoid assuming all Linux deployments are exposed; Btrfs use and backport status are the main scoping questions.
Mitigation direction
Update to a vendor kernel containing the referenced Btrfs stable fixes.
Verify distribution backports rather than relying only on upstream version numbers.
Prioritize systems using Btrfs for storage, virtualization, or critical workloads.
Check vendor advisories for any supported temporary guidance.
Validation and detection
Inventory Linux hosts and identify which use Btrfs filesystems.
Compare running kernel packages against vendor advisories and stable fix references.
Review kernel logs for Btrfs BUG_ON, panic, or transaction abort messages.
Confirm patched test systems remain stable under normal Btrfs maintenance workloads.
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-2022-50293 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.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Sep 15, 2025, 14:45 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.