udf: Mark LVID buffer as uptodate before marking it dirty
In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.270, 5.15.221, 6.1.188, 6.12.110, 6.18.52, 6.6.157, 7.2.6
- CVEs
- CVE-2026-93140
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:03 UTC · Revision 1
Source evidence
udf: Mark LVID buffer as uptodate before marking it dirty
core-osv · Original sourcePublished 17 Sept 2026, 16:11 UTC
In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078
osv:CVE-2026-93140
Kernel
Fixed versions: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6
Complete source record
{
"id": "2a6480a46ce8585b0095e788aefe7338cfe3efaf47e640e3c3d4f0f748e278ee",
"url": "https://osv.dev/vulnerability/CVE-2026-93140",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "udf: Mark LVID buffer as uptodate before marking it dirty",
"summary": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 ",
"evidence": "osv:CVE-2026-93140",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.270",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.221",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.188",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.157",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.110",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.52",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-93140",
"aliases": [
"CVE-2026-93140"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "853a0c25baf96b028de1654bea1e0c8857eadf3d"
},
{
"fixed": "e6461ef34f91ad7dbffdf912b3d661a7dd892931"
},
{
"fixed": "359cea636f4a74a96c01a8050f155e12840c079a"
},
{
"fixed": "a4c4e38b356ad4c1f90478124922917489137c08"
},
{
"fixed": "8034ddf4751d9143c5ef7eebe3d4f33218fdd378"
},
{
"fixed": "ee477e5204f764444e60699280abf5936c2a6ae6"
},
{
"fixed": "11afe1912140f79d5af3091a54b181ef72fce1a5"
},
{
"fixed": "c4058355d27488a3cd31c60c032335f77c4fdcfc"
},
{
"fixed": "fb0601134c7e51728bd098abc6909315de1e5d86"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.27.62"
},
{
"fixed": "2.6.28"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2.6.32.57"
},
{
"fixed": "2.6.33"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.0.21"
},
{
"fixed": "3.1"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.2.6"
},
{
"fixed": "3.3"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "c7da4ed95a78e38fdaffb06eaf1a3f3318b1add6"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "c005218328597211008a4d33a91e2952798e3556"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "1357ed0b4b9db30846377febb40a847d6103c991"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "43f4a516b2f5492bc597f3753b693ad8adc62748"
}
]
}
],
"versions": [
"v2.6.27.62",
"v2.6.32.71",
"v2.6.32.70",
"v2.6.32.69",
"v2.6.32.68",
"v2.6.32.67",
"v2.6.32.66",
"v2.6.32.65",
"v2.6.32.64",
"v2.6.32.63",
"v2.6.32.62",
"v2.6.32.61",
"v2.6.32.60",
"v2.6.32.59",
"v2.6.32.58",
"v2.6.32.57",
"v3.0.101",
"v3.0.100",
"v3.0.99",
"v3.0.98",
"v3.0.97",
"v3.0.96",
"v3.0.95",
"v3.0.94",
"v3.0.93",
"v3.0.92",
"v3.0.91",
"v3.0.90",
"v3.0.89",
"v3.0.88",
"v3.0.87",
"v3.0.86",
"v3.0.85",
"v3.0.84",
"v3.0.83",
"v3.0.82",
"v3.0.81",
"v3.0.80",
"v3.0.79",
"v3.0.78",
"v3.0.77",
"v3.0.76",
"v3.0.75",
"v3.0.74",
"v3.0.73",
"v3.0.72",
"v3.0.71",
"v3.0.70",
"v3.0.69",
"v3.0.68",
"v3.0.67",
"v3.0.66",
"v3.0.65",
"v3.0.64",
"v3.0.63",
"v3.0.62",
"v3.0.61",
"v3.0.60",
"v3.0.59",
"v3.0.58",
"v3.0.57",
"v3.0.56",
"v3.0.55",
"v3.0.54",
"v3.0.53",
"v3.0.52",
"v3.0.51",
"v3.0.50",
"v3.0.49",
"v3.0.48",
"v3.0.47",
"v3.0.46",
"v3.0.45",
"v3.0.44",
"v3.0.43",
"v3.0.42",
"v3.0.41",
"v3.0.40",
"v3.0.39",
"v3.0.38",
"v3.0.37",
"v3.0.36",
"v3.0.35",
"v3.0.34",
"v3.0.33",
"v3.0.32",
"v3.0.31",
"v3.0.30",
"v3.0.29",
"v3.0.28",
"v3.0.27",
"v3.0.26",
"v3.0.25",
"v3.0.24",
"v3.0.23",
"v3.0.22",
"v3.0.21",
"v3.2.102",
"v3.2.101",
"v3.2.100",
"v3.2.99",
"v3.2.98",
"v3.2.97",
"v3.2.96",
"v3.2.95",
"v3.2.94",
"v3.2.93",
"v3.2.92",
"v3.2.91",
"v3.2.90",
"v3.2.89",
"v3.2.88",
"v3.2.87",
"v3.2.86",
"v3.2.85",
"v3.2.84",
"v3.2.83",
"v3.2.82",
"v3.2.81",
"v3.2.80",
"v3.2.79",
"v3.2.78",
"v3.2.77",
"v3.2.76",
"v3.2.75",
"v3.2.74",
"v3.2.73",
"v3.2.72",
"v3.2.71",
"v3.2.70",
"v3.2.69",
"v3.2.68",
"v3.2.67",
"v3.2.66",
"v3.2.65",
"v3.2.64",
"v3.2.63",
"v3.2.62",
"v3.2.61",
"v3.2.60",
"v3.2.59",
"v3.2.58",
"v3.2.57",
"v3.2.56",
"v3.2.55",
"v3.2.54",
"v3.2.53",
"v3.2.52",
"v3.2.51",
"v3.2.50",
"v3.2.49",
"v3.2.48",
"v3.2.47",
"v3.2.46",
"v3.2.45",
"v3.2.44",
"v3.2.43",
"v3.2.42",
"v3.2.41",
"v3.2.40",
"v3.2.39",
"v3.2.38",
"v3.2.37",
"v3.2.36",
"v3.2.35",
"v3.2.34",
"v3.2.33",
"v3.2.32",
"v3.2.31",
"v3.2.30",
"v3.2.29",
"v3.2.28",
"v3.2.27",
"v3.2.26",
"v3.2.25",
"v3.2.24",
"v3.2.23",
"v3.2.22",
"v3.2.21",
"v3.2.20",
"v3.2.19",
"v3.2.18",
"v3.2.17",
"v3.2.16",
"v3.2.15",
"v3.2.14",
"v3.2.13",
"v3.2.12",
"v3.2.11",
"v3.2.10",
"v3.2.9",
"v3.2.8",
"v3.2.7",
"v3.2.6"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93140.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.3.0"
},
{
"fixed": "5.10.270"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.221"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.188"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.157"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.110"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.52"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93140.json"
}
}
],
"modified": "2026-10-28T02:30:37.161547828Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/11afe1912140f79d5af3091a54b181ef72fce1a5",
"https://git.kernel.org/stable/c/359cea636f4a74a96c01a8050f155e12840c079a",
"https://git.kernel.org/stable/c/8034ddf4751d9143c5ef7eebe3d4f33218fdd378",
"https://git.kernel.org/stable/c/a4c4e38b356ad4c1f90478124922917489137c08",
"https://git.kernel.org/stable/c/c4058355d27488a3cd31c60c032335f77c4fdcfc",
"https://git.kernel.org/stable/c/e6461ef34f91ad7dbffdf912b3d661a7dd892931",
"https://git.kernel.org/stable/c/ee477e5204f764444e60699280abf5936c2a6ae6",
"https://git.kernel.org/stable/c/fb0601134c7e51728bd098abc6909315de1e5d86",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93140.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-93140",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93140.json"
}
},
"related_cves": [
{
"value": "CVE-2026-93140",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504471,
"published_at": "2026-09-17T16:11:40.099+00:00"
}