CVE-2025-22113: Linux ext4 unmount race fix prevents kernel oops

The Linux kernel received a targeted fix for a narrowly scoped but potentially disruptive ext4 race where the filesystem could attempt to start a journaling transaction after its journal had begun teardown, tracked as CVE-2025-22113; the patch introduces an explicit mount-level flag to mark the journal as destroying and falls back to an unjournaled superblock update when that flag is set, preventing a BUG_ON that could lead to kernel oopses or availability losses during unmount/error-handling paths.

Background / Overview​

ext4 is the most widely used journaling filesystem in Linux deployments, and its reliability during mount, unmount, and error paths is critical to server availability and data integrity. The bug fixed by the upstream patch is an ordering/race condition that appears during complex teardown sequences — for example, when an unmount interleaves journal destruction with deferred superblock update work. In that scenario, a background work item (update_super_work) could attempt to start a journal transaction after the journal has been marked unmounted (JBD2_UNMOUNT), triggering a deliberately inserted BUG_ON in the journaling layer. That BUG_ON is a defensive kernel assertion that can escalate to an oops (and depending on kernel configuration, a panic), causing immediate service interruption. Multiple vulnerability trackers and vendor advisories captured the same technical summary of the problem and the upstream remediation approach, confirming this is a correctness / availability fix rather than an information disclosure or privilege‑escalation exploit in the wild. Operators should treat the issue as an operational risk that merits patching on affected platforms.

---

What went wrong — technical anatomy​

The problematic interleaving looks like this in simplified form:

• ext4_put_super runs as part of unmount and flushes pending work: flush_work(&sbi->s_sb_upd_work).
• The journaling layer (jbd2) runs jbd2_journal_destroy which sets journal->j_flags |= JBD2_UNMOUNT.
• Meanwhile, prior errors can schedule superblock update work (via schedule_work(&sbi->s_sb_upd_work)).
• When that work executes, it calls jbd2_journal_start which contains BUG_ON(journal->j_flags & JBD2_UNMOUNT).
• Because the journal was already marked unmounted, BUG_ON trips — a kernel-level failure.

The upstream patch author and reviewers reproduced this timing using stress and LTP-style workloads, showing that error-handling paths could reliably create the window for a deferred work item to try to journal an update after the journal teardown has begun. The root is not a memory corruption or security bypass — it is an unprotected ordering/race between workqueue-driven superblock updates and the journal destroy sequence.

Why the BUG_ON was there​

The BUG_ON in jbd2_journal_start is a defensive check: starting a new transaction on a journal that has been unmounted is an invalid state and historically should never be reached. The presence of the assertion is a signal that the code expects such interleavings to be impossible; the vulnerability arises when tests and real-world stress reveal that they are possible under certain error paths. Turning a hard assertion into a controlled, safe behavior is the upstream remedy pattern here: avoid hitting the assertion by ensuring work that would journal is either prevented or performed unjournaled when the journal is shutting down.

---

The upstream fix — what changed in the kernel​

The core of the remediation is a small, surgical change in fs/ext4:

• Introduce a mount-level boolean flag in the ext4 superblock state (in the patch it appears as s_journal_destorying in the code diff).
• Set this flag at the appropriate point in the journal-destroy path once all pending in-transaction FS updates are completed and just before the code enters jbd2_journal_destroy.
• When ext4 schedules deferred superblock updates (e.g., in ext4_handle_error), the code now checks !s_journal_destorying before choosing the journaled, deferred update path. If the flag is set, the code falls back to an immediate, unjournaled call to ext4_commit_super.
• The patch also initializes the flag to false during normal mount (__ext4_fill_super).

This approach avoids the BUG_ON by ensuring that no code attempts to start a journal transaction after the journal has entered its unmount/destroy phase. The upstream message and patch explicitly link the change to the earlier commit 2d01ddc86606 ("ext4: save error info to sb through journal if available") and annotate the fix as a follow-up corrective change.

Why the change is intentionally small​

Kernel maintainers favor minimal, well-scoped patches for race/ordering bugs in mature subsystems. The rationale here is:

• The fix avoids a code-path that is unsafe only in the narrow timeframe when the journal is being destroyed.
• It preserves the normal journaling behavior for the vast majority of cases where the journal is healthy and not destroying.
• The change is localized (a few lines of logic and a new boolean) and therefore has low regression risk and is easy to backport to stable kernel series.

Upstream reviewers debated subtle flush ordering and whether the workqueue should be flushed around setting the flag; the final patch reflects a consensus to set the flag only after draining appropriate update work and to trigger an unjournaled fallback where necessary. That discussion is visible in the kernel mailing list thread that carries the patch.

---

Impact and exploitability — practical risk model​

• Primary impact: Availability. The visible, plausible outcome of the race is a kernel BUG_ON leading to an oops or panic. That behavior can cause process/service interruption or host reboot depending on kernel settings.
• Attack vector: Local / operational. Triggering the race requires local actions that provoke the specific unmount / error / deferred work interleaving. This means multi‑tenant or cloud hosts (where untrusted workloads can cause mount/unmount activity or generate error paths) are more exposed than single-user desktops.
• Confidentiality/Integrity: Not demonstrated. Public records and vendor advisories describe an availability correctness issue; no credible public proof-of-concept shows that this race can be escalated into information disclosure or code execution.
• Exploitability: Low for remote attackers, but non-trivial for local users with privileges to create timing/tearing sequences on ext4 mounts. In shared hosting or CI environments that mount untrusted images or run heavy stress tests, the window for exploitation is more realistic.

Risk-scoring across vendors differs (CVSS variants in vendor trackers show a range), but the conservative operational posture is to treat this as a medium-severity availability bug and patch prioritized systems promptly. For example, some vendor trackers list a CVSS around 5.5 (medium), while live-patch vendors and some enterprise advisories treated it as moderately severe for affected environments.

---

Who should prioritize patching​

• Hosts that run multi-tenant workloads, container orchestrators, or cloud images where unprivileged workloads can mount filesystems or trigger error paths.
• CI/CD runners and build farms that mount many third-party images or use stress/ltp workloads (these environments already exercise exotic interleavings and are likely to reproduce the bug).
• Storage servers, NAS appliances, and systems that do frequent mount/unmount cycles or that use loopback/backing images from untrusted sources.
• Vendors and embedded device makers — long-tail devices running custom kernels require vendor backports and assurance that the fix made it into their kernel tree.

Lower priority: single-user desktops or locked-down servers with no untrusted local access and with limited mount activity. Nonetheless, apply standard maintenance and patch cycles for eventual remediation.

---

Detection, verification, and forensics​

Operators should verify presence or absence of the fix and monitor for symptoms:

• Commands to inventory potentially impacted hosts:
• uname -r — note the running kernel version.
• mount | grep ext4 — find ext4 mounts.
• lsmod | grep ext4 or modinfo ext4 — verify ext4 usage.
• Kernel logs to hunt for symptomatic traces:
• Look for BUG_ON or jbd2_journal_start related WARN/OOPS messages in dmesg / journalctl -k.
• Search workqueue traces that show update_super_work or ext4 superblock update entries running during unmount/put_super flow.
• Package verification:
• Confirm your distribution's kernel package changelog or security advisory explicitly lists CVE‑2025‑22113 or references the upstream patch message (the LKML patch/commit id).
• For custom kernels, search the kernel git tree for the introduced symbol/flag (e.g., s_journal_destorying or the specific diff around fs/ext4/super.c and fs/ext4/ext4_jbd2.h).
• Reproduction is delicate — only attempt in isolated labs:
• Exercise unmounts under stress, drain workqueues, and watch for BUG_ON or unexpected journal start attempts to validate a vulnerable kernel. Reproducing the race reliably is nontrivial and best done in a controlled test lab.

If you see BUG_ON traces tied to jbd2_journal_start in production, treat the host as high priority for remediation and avoid trying to trigger more reproductions on production data. Preserve dmesg and any kernel oops output for vendor triage.

---

Remediation and mitigation steps​

• Install vendor-supplied kernel updates that include the upstream fix.
• Check your distribution security tracker (Debian, Ubuntu, Red Hat, SUSE, Amazon Linux, etc. for the mapped package versions that contain CVE‑2025‑22113. Vendors have already published advisories mapping their patches to the upstream fix.
• Reboot into the patched kernel (or apply a vendor livepatch if available and trusted).
• If you cannot patch immediately, apply compensating controls:
• Restrict who can perform mounts/unmounts or provide loopback-backed images.
• Limit untrusted users’ ability to create or manipulate ext4 mounts.
• Isolate build/CI runners that accept untrusted images to dedicated hosts that can be patched first.
• For embedded and appliance vendors: request explicit backports and changelog evidence that the fix is included; do not assume surface-level kernel version numbers imply the patch is present — ask for the upstream commit ID.

Ordered rollout recommendation:

• Canary group: patch a small representative set of hosts that reflect production load/driver mix.
• Validate: perform controlled unmounts and error-path checks to ensure the BUG_ON no longer occurs.
• Broader rollout: schedule maintenance windows and patch remaining hosts, prioritizing multi-tenant and I/O-critical systems.

---

Vendor responses and distribution mapping​

Public trackers (NVD, Debian security tracker, SUSE advisory pages), cloud vendor advisories, and enterprise patch dashboards have captured CVE‑2025‑22113 and published remediation guidance. The kernel mailing list discussion and patch diff provide the canonical upstream record of the fix and the exact lines changed, which distributions used to map their packages. Operators should cross‑reference at least two sources — a vendor advisory and the upstream commit/patch — before declaring a given kernel package as remediated. Be mindful of the long-tail: OEM kernels, embedded devices, and vendor images may lag upstream and require vendor engagement. If a vendor cannot demonstrate a backport via changelog or commit-id inclusion, treat that image as unpatched.

---

Critical analysis — strengths of the fix and residual risks​

Strengths

• The remediation is small, localized, and conceptually simple: introduce a mount-level guard and fall back to a safe unjournaled path. That makes it easy to backport into stable kernel trees.
• The change preserves the normal journaling semantics for healthy runtime conditions and only alters behavior for the narrow journal-destroy window — minimizing behavioral regressions.
• The upstream discussion and patch were transparent on LKML and are traceable to a concrete fix that includes Fixes: 2d01ddc86606. That makes vendor mapping reliable.

Residual risks and caveats

• Vendor/embedded lag: small patches are easy to backport, but vendor processes and long-tail devices may still remain vulnerable for months. Maintain an inventory of devices that ship vendor kernels and track vendor advisories explicitly.
• Unverified exploitation expansion: while current public records characterize this as an availability correctness issue, kernel availability bugs have historically been used as part of larger operational attacks (e.g., causing reboots, taking down nodes during maintenance windows). Treat availability failures seriously in multi‑tenant contexts.
• Behavioral subtlety: the fix intentionally chooses an unjournaled commit in the journal‑destroying window. While reviewers judged that safe (the journal is being destroyed and there are no further pending journaled updates), complex error-handling codepaths could still present edge cases; operators should validate their workloads post-patch in staging.

Flagging unverifiable claims

• There is no credible public evidence that CVE‑2025‑22113 has been used to achieve remote code execution or privilege escalation. Claims that availability issues were weaponized into escalation chains are speculative unless accompanied by reproducible PoC or multi-stage exploit details; treat such claims cautiously until independently corroborated.

---

Practical checklist for administrators​

• Inventory:
• Identify hosts with ext4 mounts: mount | grep ext4.
• Identify kernel versions: uname -r.
• Map:
• Consult your distribution’s security advisory for CVE‑2025‑22113 and verify the package version contains the upstream patch (look for the LKML or commit reference).
• Patch:
• Install the vendor kernel update and reboot (or apply a trusted vendor livepatch).
• Validate:
• In staging, run a controlled unmount/error stress sequence and monitor dmesg for jbd2/BUG_ON traces.
• Monitor:
• Add detection rules to log aggregation for jbd2_journal_start, update_super_work, and ext4-related oops signatures.
• For long-tail devices:
• Open vendor support cases and request explicit backport confirmation or timelines.

---

Conclusion​

CVE‑2025‑22113 is a textbook example of a correctness/race fix in a mature kernel subsystem: the problem is not a memory corruption exploit but a timing window in error-unmount flows that can trigger a defensive BUG_ON in the journaling layer, causing availability failures. The upstream remedy — mark the journal as destroying and fall back to an unjournaled superblock commit when appropriate — is narrowly scoped, low-risk, and easy to backport. Operators should prioritize patching multi‑tenant, CI/build, and storage-facing hosts, verify vendor package changelogs for the upstream patch, and apply standard monitoring and isolation mitigations for hosts that cannot be immediately updated. The kernel mailing list patch thread and multiple vendor advisories document the change and provide the basis for remediation.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center