# CVE-2023-54121: btrfs: fix incorrect splitting in btrfs_drop_extent_map_range

> Incorrect extent map splitting in the Linux kernel btrfs filesystem can cause invalid memory states and system crashes during relocation.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Dec 2025
- **Updated:** 5 Aug 2026
- **Also known as:** BELL-CVE-2023-54121, DEBIAN-CVE-2023-54121, GHSA-8482-4rvj-5h62, ROOT-OS-DEBIAN-11-CVE-2023-54121, ROOT-OS-UBUNTU-2204-CVE-2023-54121, UBUNTU-CVE-2023-54121

## What is CVE-2023-54121?

CVE-2023-54121 is a high-severity memory corruption vulnerability in Linux, published on 24 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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

btrfs: fix incorrect splitting in btrfs_drop_extent_map_range

In production we were seeing a variety of WARN_ON()'s in the extent_map
code, specifically in btrfs_drop_extent_map_range() when we have to call
add_extent_mapping() for our second split.

Consider the following extent map layout

	PINNED
	[0 16K)  [32K, 48K)

and then we call btrfs_drop_extent_map_range for [0, 36K), with
skip_pinned == true.  The initial loop will have

	start = 0
	end = 36K
	len = 36K

we will find the [0, 16k) extent, but since we are pinned we will skip
it, which has this code

	start = em_end;
	if (end != (u64)-1)
		len = start + len - em_end;

em_end here is 16K, so now the values are

	start = 16K
	len = 16K + 36K - 16K = 36K

len should instead be 20K.  This is a problem when we find the next
extent at [32K, 48K), we need to split this extent to leave [36K, 48k),
however the code for the split looks like this

	split->start = start + len;
	split->len = em_end - (start + len);

In this case we have

	em_end = 48K
	split->start = 16K + 36K       // this should be 16K + 20K
	split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K

and now we have an invalid extent_map in the tree that potentially
overlaps other entries in the extent map.  Even in the non-overlapping
case we will have split->start set improperly, which will cause problems
with any block related calculations.

We don't actually need len in this loop, we can simply use end as our
end point, and only adjust start up when we find a pinned extent we need
to skip.

Adjust the logic to do this, which keeps us from inserting an invalid
extent map.

We only skip_pinned in the relocation case, so this is relatively rare,
except in the case where you are running relocation a lot, which can
happen with auto relocation on.

## Which versions are affected by CVE-2023-54121?


## How do I fix CVE-2023-54121?

Apply the vendor's patch.

## Is CVE-2023-54121 being exploited?

There is no known exploitation of CVE-2023-54121 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2023-54121 and fix it if it is affected.

What it is: CVE-2023-54121 is a high-severity memory corruption vulnerability in Linux, published on 24 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2023-54121 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. 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.
2. 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.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2023-54121/ (Markdown: https://insights.sbomify.com/CVE-2023-54121/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2023-54121
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-54121
- OSV: https://osv.dev/vulnerability/CVE-2023-54121

---
From sbomify Insights: https://insights.sbomify.com/CVE-2023-54121/
Summaries are generated and may contain mistakes; the official description above is the record.