CVE-2026-93140: 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 (endbufferwritesync()) clears the BHUptodate flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, udfopenlvid() or udfsyncfs() will modify the LVID buffer and call markbufferdirty(). This triggers a spurious WARNONONCE(!bufferuptodate(bh)) warning in markbufferdirty() 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 BHUptodate flag before calling markbufferdirty() in udfopenlvid() and udfsyncfs(). This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to udfcloselvid() 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 ]------------ !bufferuptodate(bh) WARNING: fs/buffer.c:1087 at markbufferdirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: <TASK> udfopenlvid+0x369/0x5b0 fs/udf/super.c:2078 udfreconfigure+0x336/0x540 fs/udf/super.c:679 reconfiguresuper+0x232/0x8f0 fs/super.c:1080 vfscmdreconfigure fs/fsopen.c:268 [inline] vfsfsconfiglocked+0x171/0x320 fs/fsopen.c:297 dosysfsconfig fs/fsopen.c:463 [inline] sesysfsconfig+0x6b9/0x810 fs/fsopen.c:350 dosyscall64+0x174/0x580 arch/x86/entry/syscall64.c:94 </TASK>
Affected Software
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems using the Linux kernel UDF filesystem are affected only when an I/O error occurs while writing the Logical Volume Integrity Descriptor buffer and the filesystem is later remounted read-write or synchronized.
What would indicate that a system has encountered the issue?
The observable symptom is a spurious WARN_ON_ONCE(!buffer_uptodate(bh)) warning from mark_buffer_dirty(). It can occur when udf_open_lvid() or udf_sync_fs() modifies and dirties the LVID buffer after the earlier write I/O error cleared its BH_Uptodate flag.
Does this imply that the in-memory LVID data is invalid or corrupted?
No. The described condition occurs even though the LVID buffer still contains valid in-memory data; the warning is caused by the BH_Uptodate flag having been cleared after the failed write.