LiveActive security incident?Get immediate response
CVE Record

CVE-2022-50021: ext4: block range must be validated before use in ext4_mb_clear_bb()

In the Linux kernel, the following vulnerability has been resolved: ext4: block range must be validated before use in ext4_mb_clear_bb() Block range to free is validated in ext4_free_blocks() using ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb(). However in some situations on bigalloc file system the range might be adjusted after the validation in ext4_free_blocks() which can lead to troubles on corrupted file systems such as one found by syzkaller that resulted in the following BUG kernel BUG at fs/ext4/ext4.h:3319! PREEMPT SMP NOPTI CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014 RIP: 0010:ext4_free_blocks+0x95e/0xa90 Call Trace: <TASK> ? lock_timer_base+0x61/0x80 ? __es_remove_extent+0x5a/0x760 ? __mod_timer+0x256/0x380 ? ext4_ind_truncate_ensure_credits+0x90/0x220 ext4_clear_blocks+0x107/0x1b0 ext4_free_data+0x15b/0x170 ext4_ind_truncate+0x214/0x2c0 ? _raw_spin_unlock+0x15/0x30 ? ext4_discard_preallocations+0x15a/0x410 ? ext4_journal_check_start+0xe/0x90 ? __ext4_journal_start_sb+0x2f/0x110 ext4_truncate+0x1b5/0x460 ? __ext4_journal_start_sb+0x2f/0x110 ext4_evict_inode+0x2b4/0x6f0 evict+0xd0/0x1d0 ext4_enable_quotas+0x11f/0x1f0 ext4_orphan_cleanup+0x3de/0x430 ? proc_create_seq_private+0x43/0x50 ext4_fill_super+0x295f/0x3ae0 ? snprintf+0x39/0x40 ? sget_fc+0x19c/0x330 ? ext4_reconfigure+0x850/0x850 get_tree_bdev+0x16d/0x260 vfs_get_tree+0x25/0xb0 path_mount+0x431/0xa70 __x64_sys_mount+0xe2/0x120 do_syscall_64+0x5b/0x80 ? do_user_addr_fault+0x1e2/0x670 ? exc_page_fault+0x70/0x170 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fdf4e512ace Fix it by making sure that the block range is properly validated before used every time it changes in ext4_free_blocks() or ext4_mb_clear_bb().

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel ext4 flaw can trigger a kernel BUG when handling a corrupted bigalloc ext4 filesystem. In business terms, affected systems could crash or become unavailable if they process a crafted or corrupted filesystem. The sources do not show active exploitation or a public severity score.

Executive priority

Treat this as a patching and resilience issue rather than an emergency internet-facing exposure based on the supplied evidence. Prioritize high-availability Linux systems and any environment processing external storage or filesystem images, because a kernel crash can create service interruption.

Technical view

ext4 validates a block range in ext4_free_blocks(), but on bigalloc filesystems the range can be adjusted after validation before ext4_mb_clear_bb() uses it. On corrupted filesystems, syzkaller demonstrated this could hit a kernel BUG during mount/truncate cleanup paths. The fix revalidates block ranges whenever they change.

Likely exposure

Exposure is most relevant for Linux systems that mount ext4 filesystems, especially bigalloc ext4 volumes or untrusted filesystem images. Servers that never mount attacker-controlled or removable media have lower likely exposure, but still need patched vendor kernels if in the listed affected ranges.

Exploitation context

The bundle cites a syzkaller-found corrupted filesystem crash and marks KEV as false. It provides no evidence of active exploitation, remote exploitation, privilege escalation, or weaponized public exploitation. The realistic concern from the available evidence is local or operational denial of service through malformed filesystem handling.

Researcher notes

The core security boundary is validation drift after range adjustment in ext4_free_blocks() before ext4_mb_clear_bb(). The source bundle lacks CVSS, CWE mapping, and detailed version range semantics, so affected-version analysis should be confirmed against distro kernels and the referenced stable commits.

Mitigation direction

  • Update to a vendor Linux kernel containing the referenced ext4 stable fixes.
  • Prioritize systems that mount removable media, disk images, or user-supplied ext4 filesystems.
  • Avoid mounting untrusted ext4 images on production systems until patched.
  • Check Linux distribution advisories for exact fixed package versions.
  • Document affected kernel versions and remediation status in vulnerability tracking.

Validation and detection

  • Inventory Linux kernel versions across servers, endpoints, and appliances.
  • Identify systems using ext4, especially bigalloc ext4 filesystems.
  • Confirm vendor kernel changelogs include the referenced ext4 block-range validation fix.
  • Review logs for kernel BUG, ext4 mount failures, or unexpected crashes during filesystem handling.
  • Validate patched systems with normal filesystem mount and maintenance workflows.
Prepared
Confidence
medium
Sources
6

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-2022-50021 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
Unknown
CVSS
Not scored
Known Exploited
No
Published
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.

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.

  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
LinuxLinux84130193e0e6568dfdfb823f0e1e19aec80aff6e, 84130193e0e6568dfdfb823f0e1e19aec80aff6e, 84130193e0e6568dfdfb823f0e1e19aec80aff6e, 84130193e0e6568dfdfb823f0e1e19aec80aff6eunaffected
LinuxLinux3.2, 0, 5.10.175, 5.15.103, 5.19.4, 6.0affected
Weakness

CWE details

No CWE listed

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