A Linux kernel vulnerability tracked as CVE-2025-68357 is causing kernel oopses and misattributed I/O errors on systems running heavy asynchronous read workloads, particularly those using the XFS filesystem. The flaw, introduced by a kernel change that deferred error completions to a workqueue, leaves that workqueue unallocated in certain async read paths, triggering crashes when an I/O error occurs. Patches are available in upstream stable trees, and administrators should update their kernels or apply vendor backports immediately.

What Actually Happened in the iomap Subsystem

The bug lives in the iomap framework, which centralizes file I/O mapping and writeback for modern Linux filesystems including XFS. In an effort to improve robustness, kernel commit 222f2c7c6d14 ("iomap: always run error completions in user context") moved I/O error completion handling from interrupt or tight kernel contexts into a user-context workqueue called s_dio_done_wq. The change assumed that any code path invoking the deferred completion would have the workqueue already allocated.

That assumption failed for asynchronous read paths. When an async read hit an error, the kernel tried to dispatch a work item on s_dio_done_wq, but the workqueue had never been allocated—resulting in a NULL or invalid workqueue reference. The immediate symptom is a kernel oops with stack traces pointing into iomap, direct I/O completion, or workqueue dispatch code. Administrators may also see “Buffer I/O error” messages in dmesg or journal logs for the affected block device, and sometimes errors are attributed to the wrong file altogether (for example, an fsync failure on an unrelated file). On heavily stressed systems—multi-tenant hosts, virtualization platforms, or storage servers handling intense parallel async I/O—repeated oopses can force filesystem recovery operations (umount + fsck) and degrade service availability.

The vulnerability is local: an attacker or faulty process needs local filesystem access to trigger async reads, but the impact is purely availability-focused (denial of service and operational disruption). There is no evidence of direct data exfiltration or remote code execution.

What This Means for You

The practical consequences vary depending on your role:

  • System administrators and SREs running storage servers, database hosts, virtualized platforms, or any multi-tenant Linux environment with XFS or heavy async I/O are most exposed. Unexplained crashes and garbled I/O error messages can lead to unnecessary troubleshooting cascades, forced filesystem checks, and downtime.
  • Desktop users and single‑server operators are at much lower risk unless they run workloads that generate sustained high‑concurrency async reads (e.g., certain scientific simulations, large file processing, or continuous integration pipelines).
  • Kernel packagers and distribution maintainers must backport the upstream fix correctly, test under representative I/O stress, and clearly document the CVE in changelogs so that downstream admins can verify patching status.

In short, if you manage Linux systems that process heavy I/O, treat CVE-2025-68357 as a high‑priority patch. The bug may not corrupt data directly, but misattributed errors and filesystem recovery can easily escalate to data integrity concerns in complex storage stacks.

How We Got Here: A Timeline of the Flaw

The iomap subsystem has been gradually refined to handle error completions more safely. Before commit 222f2c7c6d14, error callbacks could fire in hard IRQ or softirq context, which is unsafe for complex operations. The commit deferred those completions to a workqueue, a well‑established pattern in the kernel.

However, the patch only ensured s_dio_done_wq was allocated for the synchronous and write paths that the author tested. Asynchronous read paths that invoked the same deferred completion code were overlooked. This gap sat unnoticed until users with heavy async read workloads began hitting the NULL‑workqueue oops. The Linux kernel security team assigned CVE-2025-68357, and the fix was committed to upstream stable trees with specific commit IDs (recorded in public vulnerability databases). Now, Linux distributions are in the process of backporting the fix into their supported kernel packages.

What to Do Now: Patching, Verification, and Mitigations

1. Check if you are affected

  • Run uname -r to determine your running kernel version.
  • Consult your distribution’s security tracker or package changelog for any mention of CVE-2025-68357 or the upstream commit references.
  • Inspect your kernel logs for telltale signatures. Use commands like:
    bash journalctl -k | grep -E 'iomap|s_dio_done_wq|dio|Buffer I/O error' dmesg | grep -i 'Buffer I/O error'
    If you see kernel oopses containing iomap/dio/workqueue symbols, your system is likely impacted.

2. Apply the patch

  • For distribution‑managed systems: Watch for kernel updates that explicitly list CVE-2025-68357 in the changelog. Stage the update on a canary system first, then roll out to production after stress‑testing.
  • For custom or self‑built kernels:
    1. Obtain the upstream stable commits that fix this CVE from the official Linux kernel repository (the commit IDs are referenced in the CVE record and public advisories).
    2. Backport the change to your kernel branch.
    3. Rebuild and test under heavy async I/O workloads using tools like fio with direct=1 and rw=randread.
    4. Deploy to production once validated.

3. Verify the fix

  • Re‑run your I/O stress tests and confirm that no iomap‑related oopses appear in logs.
  • If you have the kernel source package, inspect the iomap error‑completion code to ensure s_dio_done_wq is allocated for async read paths.

4. Mitigations if you cannot patch immediately

  • Reduce async I/O concurrency: throttle application‑level parallelism or adjust VM/container I/O limits.
  • Isolate untrusted tenants: move users or processes that might trigger the bug off shared hosts.
  • Enable kernel crash dumps (kdump) and configure log alerting for oops patterns so you can capture evidence of the bug.

These mitigations are temporary; the only durable fix is a patched kernel.

Outlook

Distributions are actively backporting the upstream fix. Expect updated kernel packages from major vendors within their regular security update cadences. For long‑term support (LTS) kernels and embedded systems, tracking vendor‑specific advisories remains essential because version numbers alone may not confirm a fix.

Once patched, continue monitoring kernel logs for a few weeks to catch any regressions. The iomap layer is heavily exercised, so subtle backport errors are possible if the patch was not adapted for older codebases. The Linux kernel community’s quick response underscores the importance of rigorous testing for resource allocation invariants, especially in the I/O hot path.

In the meantime, if you run XFS or any storage stack that leans on iomap, bump this CVE up your patching priority list—a kernel oops during peak hours is never a welcome visitor.