Description
In the Linux kernel, the following vulnerability has been resolved:

writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes

cleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes
per call and is called again until the dying wb is drained, but every
call walks wb->b_attached and then wb->b_dirty_time from the same end.
Inodes already prepared (they stay on the list with I_WB_SWITCH set
until the switch worker runs) and inodes that cannot be switched
(I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb)
stay where they are, so each pass rescans a growing run of them under
wb->list_lock and a full drain is quadratic in the number of inodes on
the list. With ~17M inodes attached to one dying cgwb we saw this end
in soft lockups, with CPUs reported stuck for 21-48s.

Walk both lists from the oldest end and move every scanned inode to
the newest end, so the next pass starts where the previous one stopped
and the drain becomes linear. b_attached is unordered, so nobody sees
the reorder there. b_dirty_time is ordered by dirtied_when, but the
oldest unscanned inode stays at the end move_expired_inodes() picks
from, sync takes the whole list regardless of order, and prepared
inodes leave the list as soon as the switch work runs and get a new
dirtied_time_when on the new wb anyway, so the only inodes left out of
order are the ones that can never switch (DAX), and only on the dying
wb.
Published: 2026-10-18
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service via soft lockups
Action: Immediate Patch
AI Analysis

Impact

The flaw lies in the Linux kernel’s writeback subsystem, specifically the cleanup_offline_cgwb() routine. Each invocation scans the wb->b_attached and wb->b_dirty_time lists from the same end, leaving inodes that cannot be switched in place. With each pass a larger segment of the list is rescanned, turning an expected linear drain into a quadratic operation. Under heavy inode workloads, such as when ~17 million inodes are attached to a dying writeback workqueue, CPU usage spikes and the system experiences soft lockups lasting from 21 to 48 seconds, effectively halting responsiveness.

Affected Systems

All Linux kernel releases that include the default writeback logic before the patch commit 2d1da58c79b66646721a644c6eb4dd1f9c5c9327 are affected. This includes mainstream distributions—Ubuntu, Debian, Red Hat Enterprise Linux, CentOS, Fedora—whichever ship upstream kernels without custom modifications to the writeback subsystem.

Risk and Exploitability

No CVSS or EPSS values are published, indicating uncertainty about exploitation likelihood. The vulnerability is not listed in the CISA KEV catalog, suggesting it has not yet been widely exploited. Exploitation requires kernel‑level code execution or privileged actions that generate a massive inode workload. Once triggered, the system suffers a denial of service without any network interaction, making detection difficult until the lockup manifests.

Generated by OpenCVE AI on October 19, 2026 at 00:53 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a kernel update that includes patch commit 2d1da58c79b66646721a644c6eb4dd1f9c5c9327 or a later release that rewires inode drainage to linear time.
  • If an immediate kernel upgrade is not possible, mitigate temporarily by disabling DAX support, reducing large inode workloads, and limiting writeback activity to prevent the quadratic drain from occurring.
  • Configure writeback settings, such as reducing the writeback interval or threshold, to lessen the impact of large inode lists during high I/O periods.

Generated by OpenCVE AI on October 19, 2026 at 00:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 19 Oct 2026 01:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-770

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes cleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes per call and is called again until the dying wb is drained, but every call walks wb->b_attached and then wb->b_dirty_time from the same end. Inodes already prepared (they stay on the list with I_WB_SWITCH set until the switch worker runs) and inodes that cannot be switched (I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb) stay where they are, so each pass rescans a growing run of them under wb->list_lock and a full drain is quadratic in the number of inodes on the list. With ~17M inodes attached to one dying cgwb we saw this end in soft lockups, with CPUs reported stuck for 21-48s. Walk both lists from the oldest end and move every scanned inode to the newest end, so the next pass starts where the previous one stopped and the drain becomes linear. b_attached is unordered, so nobody sees the reorder there. b_dirty_time is ordered by dirtied_when, but the oldest unscanned inode stays at the end move_expired_inodes() picks from, sync takes the whole list regardless of order, and prepared inodes leave the list as soon as the switch work runs and get a new dirtied_time_when on the new wb anyway, so the only inodes left out of order are the ones that can never switch (DAX), and only on the dying wb.
Title writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-18T15:18:05.901Z

Reserved: 2026-09-25T10:25:14.356Z

Link: CVE-2026-98538

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:05.613

Modified: 2026-10-18T16:17:05.613

Link: CVE-2026-98538

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-19T03:30:06Z

Weaknesses
  • CWE-770

    Allocation of Resources Without Limits or Throttling