---
id: "CVE-2026-98538"
kind: "vulnerability"
aliases: ["CVE-2026-98538"]
title: "Linux kernel: writeback cleanup rescans inodes quadratically, causing lockups"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["kubernetes", "linux-kernel", "other", "self-hosted"]
not_affected_if: ["unknown"]
published_at: "2026-10-18T16:17:05+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:23:45+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98538", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel: writeback cleanup rescans inodes quadratically, causing lockups

When a memory cgroup's writeback context is torn down with millions of inodes attached, the kernel rescans the same inodes on every pass, so draining the list takes quadratic time and can freeze CPUs for tens of seconds. The sources describe a denial-of-service style stall from a kernel bug, not a confirmed code execution or data-theft path.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel version that contains the upstream fix for CVE-2026-98538 (unknown in the sources)
- Check whether the host runs many inodes on memory cgroups with heavy file churn, e.g. `cat /proc/meminfo | grep -i dirty` showing large dirty values during cgroup teardown

## Fix

- Update the Linux kernel to a stable release that includes the upstream commit for CVE-2026-98538 (version unknown in the sources)
- Follow your distribution's kernel advisory for the fixed package

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98538

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_