CVE-2026-93140

CVE CVE-2026-93140EUVD EUVD-2026-82248Published 2026-09-17T16:11:40.000Z

What the advisory describes

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: <TASK> udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 </TASK>

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 853a0c25baf96b028de1654bea1e0c8857eadf3d <fb0601134c7e51728bd098abc6909315de1e5d86; patch: 0; 853a0c25baf96b028de1654bea1e0c8857eadf3d <11afe1912140f79d5af3091a54b181ef72fce1a5; 853a0c25baf96b028de1654bea1e0c8857eadf3d <359cea636f4a74a96c01a8050f155e12840c079a; patch: 6.1.188; patch: 7.2.6; c005218328597211008a4d33a91e2952798e3556; patch: 7.3-rc1; 853a0c25baf96b028de1654bea1e0c8857eadf3d <ee477e5204f764444e60699280abf5936c2a6ae6; 3.0.21 <3.1; 853a0c25baf96b028de1654bea1e0c8857eadf3d <e6461ef34f91ad7dbffdf912b3d661a7dd892931; c7da4ed95a78e38fdaffb06eaf1a3f3318b1add6; patch: 5.10.270; patch: 5.15.221; 3.3; 3.2.6 <3.3; patch: 6.18.52; 853a0c25baf96b028de1654bea1e0c8857eadf3d <a4c4e38b356ad4c1f90478124922917489137c08; patch: 6.6.157; 853a0c25baf96b028de1654bea1e0c8857eadf3d <8034ddf4751d9143c5ef7eebe3d4f33218fdd378; 1357ed0b4b9db30846377febb40a847d6103c991; 2.6.32.57 <2.6.33; 43f4a516b2f5492bc597f3753b693ad8adc62748; patch: 6.12.110; 2.6.27.62 <2.6.28; 853a0c25baf96b028de1654bea1e0c8857eadf3d <c4058355d27488a3cd31c60c032335f77c4fdcfc

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.