{"id":"CVE-2026-98445","title":"xfs: don't let memory failures leak blocks and kill repairs","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: don't let memory failures leak blocks and kill repairs\n\nLOLLM complains that a memory allocation failure in\nxrep_newbt_add_blocks results in online repair leaking …","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= be408417630427984a1fddd069f30b245793234c < 3380151cf0ce8ad0c1d356fed51e4b69e1d28e50","Linux >= be408417630427984a1fddd069f30b245793234c < b15c79fca28060fd9c7e77f2c3ebc4ba023974e8","Linux >= be408417630427984a1fddd069f30b245793234c < 0e0d3372a84029da1768c7a4c4601484af5b58a2","Linux >= be408417630427984a1fddd069f30b245793234c < ab1c416d2377cdc16123ef521aac4da1c468c3d4","Linux 6.8"],"published":"2026-10-18","updated":"2026-10-18","sourceUpdated":"2026-10-18T15:14:55.754Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-98445","references":[{"url":"https://git.kernel.org/stable/c/3380151cf0ce8ad0c1d356fed51e4b69e1d28e50"},{"url":"https://git.kernel.org/stable/c/b15c79fca28060fd9c7e77f2c3ebc4ba023974e8"},{"url":"https://git.kernel.org/stable/c/0e0d3372a84029da1768c7a4c4601484af5b58a2"},{"url":"https://git.kernel.org/stable/c/ab1c416d2377cdc16123ef521aac4da1c468c3d4"}],"tags":["cve.org"],"ingestedAt":"2026-10-18T15:45:12.305Z","slug":"CVE-2026-98445","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: don't let memory failures leak blocks and kill repairs\n\nLOLLM complains that a memory allocation failure in\nxrep_newbt_add_blocks results in online repair leaking blocks that were\npreviously allocated to write a new btree, but the problem is worse than\nthat -- a limitation of the codebase is that the callers cannot undo the\ntransaction /and/ return the error -- either you undo all changes and\ncommit the transaction, or you error out and the filesystem goes down.\n\nHowever, the new btree space reservation object isn't that big (~48\nbytes).  Let's just do a NOFAIL allocation and the problem goes away.\n\n## Affected\n\n- `Linux >= be408417630427984a1fddd069f30b245793234c < 3380151cf0ce8ad0c1d356fed51e4b69e1d28e50`\n- `Linux >= be408417630427984a1fddd069f30b245793234c < b15c79fca28060fd9c7e77f2c3ebc4ba023974e8`\n- `Linux >= be408417630427984a1fddd069f30b245793234c < 0e0d3372a84029da1768c7a4c4601484af5b58a2`\n- `Linux >= be408417630427984a1fddd069f30b245793234c < ab1c416d2377cdc16123ef521aac4da1c468c3d4`\n- `Linux 6.8`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}