---
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:

  xfs: don't let memory failures leak blocks and kill repairs

  LOLLM complains that a memory allocation failure in
  xrep_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'
---

## Overview

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

xfs: don't let memory failures leak blocks and kill repairs

LOLLM complains that a memory allocation failure in
xrep_newbt_add_blocks results in online repair leaking blocks that were
previously allocated to write a new btree, but the problem is worse than
that -- a limitation of the codebase is that the callers cannot undo the
transaction /and/ return the error -- either you undo all changes and
commit the transaction, or you error out and the filesystem goes down.

However, the new btree space reservation object isn't that big (~48
bytes).  Let's just do a NOFAIL allocation and the problem goes away.

## Affected

- `Linux >= be408417630427984a1fddd069f30b245793234c < 3380151cf0ce8ad0c1d356fed51e4b69e1d28e50`
- `Linux >= be408417630427984a1fddd069f30b245793234c < b15c79fca28060fd9c7e77f2c3ebc4ba023974e8`
- `Linux >= be408417630427984a1fddd069f30b245793234c < 0e0d3372a84029da1768c7a4c4601484af5b58a2`
- `Linux >= be408417630427984a1fddd069f30b245793234c < ab1c416d2377cdc16123ef521aac4da1c468c3d4`
- `Linux 6.8`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.