ghsa-95qf-frmh-4g6j
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2023-53429"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T16:15:46Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don\u0027t check PageError in __extent_writepage\n\n__extent_writepage currenly sets PageError whenever any error happens,\nand the also checks for PageError to decide if to call error handling.\nThis leads to very unclear responsibility for cleaning up on errors.\nIn the VM and generic writeback helpers the basic idea is that once\nI/O is fired off all error handling responsibility is delegated to the\nend I/O handler. But if that end I/O handler sets the PageError bit,\nand the submitter checks it, the bit could in some cases leak into the\nsubmission context for fast enough I/O.\n\nFix this by simply not checking PageError and just using the local\nret variable to check for submission errors. This also fundamentally\nsolves the long problem documented in a comment in __extent_writepage\nby never leaking the error bit into the submission context.",
"id": "GHSA-95qf-frmh-4g6j",
"modified": "2025-09-18T18:30:27Z",
"published": "2025-09-18T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53429"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e92499e3b004baffb479d61e191b41b604ece9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d40be032ecd8ee1ca033bee43c7755d21fb4d72a"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.