---
id: "CVE-2026-98959"
kind: "vulnerability"
aliases: ["CVE-2026-98959"]
title: "Linux btrfs: replacing one xattr corrupts shared directory item, losing attributes"
severity: "low"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["btrfs", "infrastructure", "linux", "self-hosted"]
not_affected_if: ["default-config", "no-btrfs"]
published_at: "2026-10-23T13:17:17+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98959", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98959", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux btrfs: replacing one xattr corrupts shared directory item, losing attributes

In the Linux kernel's btrfs filesystem, replacing the value of an extended attribute with a different-sized value can leave a packed directory item uninitialized, corrupting metadata. The sources describe the result as a lost xattr and a transaction abort on unmount, not a clear attacker capability.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and check whether the kernel is a release that includes the upstream btrfs fix (unknown from the sources)
- Check whether the filesystem is btrfs with `findmnt -t btrfs`
- Look for `BTRFS warning` or tree-checker errors in `dmesg`

## Fix

- Update the Linux kernel to a release that contains the upstream btrfs xattr fix (exact version unknown from the sources)
- Avoid replacing xattrs on btrfs volumes until patched if the update cannot be applied

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98959
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98959

## From the sources

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

btrfs: fix xattr replace when multiple xattrs are packed in the same item

If we have a btrfs_dir_item item that packs multiple xattrs and then we
replace the value of one of them (with the setxattr(2) family of syscalls)
with another value of a different size, we end up not having a fully
initialized btrfs_dir_item, resulting in a corruption that the tree
checker will detect at extent buffer writeback time.

This is because in btrfs_setxattr() when we find a btrfs_dir_item with
multiple xattrs (due to the crc32c hash of their name being the same)
we delete one of the xattr items (btrfs_dir_item) and then insert a new
one, but the deletion and insertion results in shifting existing data in
the leaf and therefore when the new value of a xattr has a different size,
the new btrfs_dir_item is placed in a leaf section that was not
initialized and we only copy the value's data and set the value's length
in the new btrfs_dir_item, without setting the name, the name's length,
the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) and
transaction ID.

The following script reproduces the issue:

  $ cat test.sh
  #!/bin/bash

  DEV=/dev/sdi
  MNT=/mnt/sdi

  mkfs.btrfs -f $DEV
  mount $DEV $MNT

  touch $MNT/testfile

  # Add two xattrs that, on btrfs, have the same hash (crc32c) for their
  # name and therefore are packed into the same btrfs_dir_item.
  setfattr -n user.foobar -v 123 $MNT/testfile
  setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile

  # Verify the xattrs are present.
  echo "xattrs before:"
  getfattr --absolute-names --dump $MNT/testfile

  # Now replace the value of the foobar xattr with a significantly larger
  # value.
  setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile

  # Check the xattrs have the expected values.
  echo "xattrs after:"
  getfattr --absolute-names --dump $MNT/testfile

  umount $MNT

Running it:

  $ ./test.sh
  (...)
  xattrs before:
  # file: /mnt/sdi/testfile
  user.WvG1c1Td="qwerty"
  user.foobar="123"

  xattrs after:
  # file: /mnt/sdi/testfile
  user.WvG1c1Td="qwerty"

So the "user.foobar" xattr is missing and there was a transaction abort
when unmounting the fs with the following traces in dmesg:

  $ dmesg
  [869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964
  [869800.159293] ------------[ cut here ]------------
  [869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179
  [869800.168961] Modules linked in: btrfs dm_thin_pool (...)
  [869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G        W           7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full)
  [869800.193726] Tainted: [W]=WARN
  [869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
  [869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs]
  [869800.198985] Code: 48 8b 7b 18 (...)
  [869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246
  [869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000
  [869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0
  [869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff
  [869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c
  [869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069
  [869800.229097] FS:  00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000
  [869800.231137] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0
  [869800.233783] Call Trace:
  [869800.234330]  <TASK>
  [869800.234791]  read_extent_buffer+0x4d/0x100 [btrfs]
  [869800.235898]  btrfs_listxattr+0x199/0x240 [btrfs]
  [869800.236912]  vfs_listxattr+0x51/0
---truncated---

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_