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

fs: avoid repeated scans in evict_inodes()

We observed hung tasks when users attempted to unmount a filesystem
after its disk had been removed while still in use. During device
removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount.

Each time evict_inodes() drops s_inode_list_lock to reschedule, it
restarts the walk from the head of s_inodes. With many referenced inodes
at the head of the list, these restarts repeatedly scan the same inodes
without reclaiming them. This can keep s_umount held for a long time,
blocking concurrent umount attempts and triggering hung-task reports.

Keep the current inode, already marked I_FREEING, out of the disposal
batch until s_inode_list_lock is reacquired. Resume the walk from this
inode and dispose of it in a later batch or at the end of the walk.

The zero-refcount and state checks under i_lock allow this walker to
claim the inode by setting I_FREEING and removing it from the LRU.
Other reclaimers skip the inode, leaving this walker responsible for
eviction. Only evict() removes it from s_inodes, so keeping it out of
the disposal batch ensures that it remains on the list while the lock
is dropped. After reacquiring the lock, reading its current next pointer
accounts for concurrent removal of following inodes.

The existing inode lifetime rules prohibit acquiring a reference to an
inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to
hold i_lock and establish that taking a reference is valid. Inode lookup
and igrab() check these flags under i_lock when acquiring a reference
from zero. ihold() requires an existing reference, which would keep
i_count nonzero and prevent this walker from claiming the inode. These
rules already allow iput_final() and the inode shrinker to release
i_lock after setting I_FREEING and before eviction completes.

A temporary __iget() reference would also keep the inode on the list,
but its release must preserve last-reference handling. Another user can
acquire a reference, update lazy timestamps and drop its reference while
the pin is held. If the pin becomes the last reference, dropping it with
atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime
handling and can lose those timestamp updates.

Releasing the pin with iput() preserves that handling, but does not
guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput()
may retain the inode in cache, whereas evict_inodes() must evict eligible
zero-reference inodes. The inode may also have been freed when iput()
returns, so the walker cannot then use it to force eviction. Using
I_FREEING preserves the existing eviction behavior without introducing
an additional last-reference transition.

The xfstests auto group passed on ext4 and XFS with known unrelated
failures excluded. No new issues were observed, and the previously
reproducible hung task no longer occurs with this patch.
Published: 2026-10-23
Score: 4.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service due to hung unmount operations
Action: Immediate Patch
AI Analysis

Impact

The vulnerability occurs in the Linux kernel’s inode eviction routine. While evict_inodes() releases the inode list lock to allow other work, it restarts the traversal from the head of the inode list each time the lock is dropped. With many inodes queued for eviction at the list head, this restart repeatedly scans the same set of inodes without reclaiming them, keeping the unmount semaphore s_umount held for an extended period. The effect is that any concurrent attempt to unmount the filesystem is blocked, and the kernel may report a hung task, effectively creating a denial‑of‑service scenario. The weakness underlying this behavior is a race condition and improper iteration that fail to progress when the lock state changes.

Affected Systems

Affected systems are all Linux kernel implementations that contain the unmodified evict_inodes logic. No specific kernel release numbers are provided, so any kernel version compiled from source before the patch commits listed in the references is potentially susceptible. The vulnerability is mitigated in later kernels where the walk is adjusted to skip inodes already marked I_FREEING and to resume from the correct position after reacquiring the lock.

Risk and Exploitability

Risk and exploitability assessment: The CVSS score is 4.4, the EPSS score is less than 1%, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires a scenario where a device is removed while a filesystem remains in use, causing the kernel to invoke evict_inodes during disk removal. While this can be crafted by an attacker with local privileges and hardware access, the impact is a local denial‑of‑service rather than remote code execution. Given the potential for system instability and the need for an up‑to‑date kernel, the recommended action is to apply the patch promptly.

Generated by OpenCVE AI on October 29, 2026 at 20:22 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the fix (e.g., the commits referenced: 3cdc6e12ff79f0f8a3ba62d7e61474ae4b5e119a, 7459c021874246c196f397686e100702f059b9e7, e4f3e476cd4066a815ef68cd6caa1828b9c167d5).
  • If a direct kernel upgrade is not immediately feasible, schedule a maintenance window to apply the upstream patch and rebuild local kernel modules to ensure the corrected evict_inodes logic is present.
  • After the update, validate that unmount operations no longer trigger hung‑task reports by running filesystem tests such as xfstests or performing manual unmount after simulated device removal.

Generated by OpenCVE AI on October 29, 2026 at 20:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
History

Thu, 29 Oct 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-504

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-835
References
Metrics threat_severity

None

 cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Fri, 23 Oct 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-504

Fri, 23 Oct 2026 16:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: fs: avoid repeated scans in evict_inodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount. Each time evict_inodes() drops s_inode_list_lock to reschedule, it restarts the walk from the head of s_inodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep s_umount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked I_FREEING, out of the disposal batch until s_inode_list_lock is reacquired. Resume the walk from this inode and dispose of it in a later batch or at the end of the walk. The zero-refcount and state checks under i_lock allow this walker to claim the inode by setting I_FREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from s_inodes, so keeping it out of the disposal batch ensures that it remains on the list while the lock is dropped. After reacquiring the lock, reading its current next pointer accounts for concurrent removal of following inodes. The existing inode lifetime rules prohibit acquiring a reference to an inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to hold i_lock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under i_lock when acquiring a reference from zero. ihold() requires an existing reference, which would keep i_count nonzero and prevent this walker from claiming the inode. These rules already allow iput_final() and the inode shrinker to release i_lock after setting I_FREEING and before eviction completes. A temporary __iget() reference would also keep the inode on the list, but its release must preserve last-reference handling. Another user can acquire a reference, update lazy timestamps and drop its reference while the pin is held. If the pin becomes the last reference, dropping it with atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime handling and can lose those timestamp updates. Releasing the pin with iput() preserves that handling, but does not guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput() may retain the inode in cache, whereas evict_inodes() must evict eligible zero-reference inodes. The inode may also have been freed when iput() returns, so the walker cannot then use it to force eviction. Using I_FREEING preserves the existing eviction behavior without introducing an additional last-reference transition. The xfstests auto group passed on ext4 and XFS with known unrelated failures excluded. No new issues were observed, and the previously reproducible hung task no longer occurs with this patch.
Title fs: avoid repeated scans in evict_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 Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-23T12:05:50.501Z

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

Link: CVE-2026-98924

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:13.083

Modified: 2026-10-23T13:17:13.083

Link: CVE-2026-98924

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-98924 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T20:30:18Z

Weaknesses
  • CWE-835

    Loop with Unreachable Exit Condition ('Infinite Loop')