{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98924 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-98924 is a vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-98924 and fix it if it is affected.\n\nWhat it is: CVE-2026-98924 is a vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-98924 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98924/ (Markdown: https://insights.sbomify.com/CVE-2026-98924/index.md)","id":"CVE-2026-98924","markdown":"https://insights.sbomify.com/CVE-2026-98924/index.md","name":"CVE-2026-98924","record":{"aliases":["AZL-110702","BELL-CVE-2026-98924","DEBIAN-CVE-2026-98924","GHSA-fcgw-j977-c8rv","UBUNTU-CVE-2026-98924"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: avoid repeated scans in evict_inodes()\n\nWe observed hung tasks when users attempted to unmount a filesystem\nafter its disk had been removed while still in use. During device\nremoval, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount.\n\nEach time evict_inodes() drops s_inode_list_lock to reschedule, it\nrestarts the walk from the head of s_inodes. With many referenced inodes\nat the head of the list, these restarts repeatedly scan the same inodes\nwithout reclaiming them. This can keep s_umount held for a long time,\nblocking concurrent umount attempts and triggering hung-task reports.\n\nKeep the current inode, already marked I_FREEING, out of the disposal\nbatch until s_inode_list_lock is reacquired. Resume the walk from this\ninode and dispose of it in a later batch or at the end of the walk.\n\nThe zero-refcount and state checks under i_lock allow this walker to\nclaim the inode by setting I_FREEING and removing it from the LRU.\nOther reclaimers skip the inode, leaving this walker responsible for\neviction. Only evict() removes it from s_inodes, so keeping it out of\nthe disposal batch ensures that it remains on the list while the lock\nis dropped. After reacquiring the lock, reading its current next pointer\naccounts for concurrent removal of following inodes.\n\nThe existing inode lifetime rules prohibit acquiring a reference to an\ninode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to\nhold i_lock and establish that taking a reference is valid. Inode lookup\nand igrab() check these flags under i_lock when acquiring a reference\nfrom zero. ihold() requires an existing reference, which would keep\ni_count nonzero and prevent this walker from claiming the inode. These\nrules already allow iput_final() and the inode shrinker to release\ni_lock after setting I_FREEING and before eviction completes.\n\nA temporary __iget() reference would also keep the inode on the list,\nbut its release must preserve last-reference handling. Another user can\nacquire a reference, update lazy timestamps and drop its reference while\nthe pin is held. If the pin becomes the last reference, dropping it with\natomic_dec_and_test() and evicting directly bypasses iput()'s lazytime\nhandling and can lose those timestamp updates.\n\nReleasing the pin with iput() preserves that handling, but does not\nguarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput()\nmay retain the inode in cache, whereas evict_inodes() must evict eligible\nzero-reference inodes. The inode may also have been freed when iput()\nreturns, so the walker cannot then use it to force eviction. Using\nI_FREEING preserves the existing eviction behavior without introducing\nan additional last-reference transition.\n\nThe xfstests auto group passed on ext4 and XFS with known unrelated\nfailures excluded. No new issues were observed, and the previously\nreproducible hung task no longer occurs with this patch.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"fs: avoid repeated scans in evict_inodes()","id":"CVE-2026-98924","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"bpf, sockmap: Fix self-redirect copied_seq double-counting","id":"CVE-2026-98925"},"packages":[],"prev":{"headline":"arm64: io: Reject non-user protection in ioremap_prot()","id":"CVE-2026-98923"},"products":["Linux"],"published":"2026-10-23","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-23","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-98924/"}