High · CVSS 7.8CVE-2023-53429

btrfs: don't check PageError in __extent_writepageCVE-2023-53429

Answer in brief

CVE-2023-53429 records a High severity (CVSS 7.8) vulnerability in btrfs: don't check PageError in __extent_writepage. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Sep 18, 2025Updated Oct 3, 2026Source checked Nov 5, 2026First seen by HOL Aug 4, 2026Material review Oct 3, 2026

Upstream Advisory

Key facts

Risk: High · CVSS 7.8
Exploitation: Not marked as known exploited
Affected software: 4 mapped packages or products
Fix availability: Available

Why this deserves its current priority

CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Affected products and reported versions
Product	Affected versions	Fixed versions
cpe:2.3:o:linux:linux_kernel::::::::	Not reported	Not reported

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=61391d562229ed94899ed4b4973dc2f0c015292a <d40be032ecd8ee1ca033bee43c7755d21fb4d72a \|\| >=61391d562229ed94899ed4b4973dc2f0c015292a <3e92499e3b004baffb479d61e191b41b604ece9a	d40be032ecd8ee1ca033bee43c7755d21fb4d72a, 3e92499e3b004baffb479d61e191b41b604ece9a
Linux/Linuxgeneric	3.16	Not reported
Linux/Linuxgeneric	>=61391d562229ed94899ed4b4973dc2f0c015292a <3c26023365a955d2d69355f5167508a963e44333 \|\| >=61391d562229ed94899ed4b4973dc2f0c015292a <d40be032ecd8ee1ca033bee43c7755d21fb4d72a \|\| >=61391d562229ed94899ed4b4973dc2f0c015292a <3e92499e3b004baffb479d61e191b41b604ece9a	3c26023365a955d2d69355f5167508a963e44333, d40be032ecd8ee1ca033bee43c7755d21fb4d72a, 3e92499e3b004baffb479d61e191b41b604ece9a

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to d40be032ecd8ee1ca033bee43c7755d21fb4d72a; Linux/Linux to 3c26023365a955d2d69355f5167508a963e44333 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 18, 2025
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Oct 3, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Aug 4, 2026

Sources and claim methodology

Upstream source 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.

Quoted source text, attributed separately from HOL analysis.