UBUNTU-CVE-2026-98924: Medium severity ubuntu/linux-aws vulnerability
In the Linux kernel, the following vulnerability has been resolved: fs: avoid repeated scans in evictinodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fsbdevmarkdead() calls evictinodes() while holding sumount. Each time evictinodes() drops sinodelistlock to reschedule, it restarts the walk from the head of sinodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep sumount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked IFREEING, out of the disposal batch until sinodelistlock 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 ilock allow this walker to claim the inode by setting IFREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from sinodes, 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 IFREEING or IWILLFREE. iget() requires its caller to hold ilock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under ilock when acquiring a reference from zero. ihold() requires an existing reference, which would keep icount nonzero and prevent this walker from claiming the inode. These rules already allow iputfinal() and the inode shrinker to release ilock after setting IFREEING 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 atomicdecandtest() 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. fsbdevmarkdead() runs with SBACTIVE set, so iput() may retain the inode in cache, whereas evictinodes() 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 IFREEING 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which environments are most likely to experience this issue?
The described condition occurs when a disk is removed while its filesystem remains mounted and in use, especially where many referenced inodes are present. It can affect the listed Ubuntu Linux kernel packages, including standard, AWS, Azure, GCP, and FIPS variants.
Does exploitation require a remote attacker?
No attacker action or remote attack path is described. The reported trigger is an operational scenario involving removal of an in-use storage device followed by filesystem eviction or unmount activity.
How can administrators recognize that the system is affected?
Indicators include hung-task reports during or after removal of an in-use disk and concurrent unmount attempts blocking for an extended time. The blockage occurs because the kernel holds the filesystem's s_umount lock while repeatedly scanning referenced inodes.