{"id":25997,"date":"2026-09-18T04:32:12","date_gmt":"2026-09-17T20:32:12","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-93140"},"modified":"2026-09-18T04:32:12","modified_gmt":"2026-09-17T20:32:12","slug":"cve-2026-93140","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-93140","title":{"rendered":"CVE-2026-93140 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Mark LVID buffer"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>udf: Mark LVID buffer as uptodate before marking it dirty<\/p>\n<p>When an I\/O error occurs while writing the Logical Volume Integrity<br \/>\nDescriptor (LVID) buffer to the block device, the block layer&#8217;s completion<br \/>\nhandler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the<br \/>\nbuffer. However, the buffer still contains valid LVID data in memory. If<br \/>\nthe filesystem is subsequently remounted read-write or synced,<br \/>\n`udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call<br \/>\n`mark_buffer_dirty()`. This triggers a spurious<br \/>\n`WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()`<br \/>\nbecause the buffer is not marked uptodate, even though its in-memory<br \/>\ncontents are valid and are about to be overwritten.<\/p>\n<p>To prevent this spurious warning, unconditionally set the `BH_Uptodate`<br \/>\nflag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and<br \/>\n`udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and<br \/>\nmatches the workaround previously applied to `udf_close_lvid()` in commit<br \/>\n853a0c25baf9 (&#8220;udf: Mark LVID buffer as uptodate before marking it dirty&#8221;).<br \/>\nExtending this workaround ensures consistent behavior across all LVID<br \/>\nupdates.<\/p>\n<p>Buffer I\/O error on dev loop0, logical block 128, lost sync page write<br \/>\n&#8212;&#8212;&#8212;&#8212;[ cut here ]&#8212;&#8212;&#8212;&#8212;<br \/>\n!buffer_uptodate(bh)<br \/>\nWARNING: fs\/buffer.c:1087 at mark_buffer_dirty+0x299\/0x410 fs\/buffer.c:1087<br \/>\n&#8230;<br \/>\nCall Trace:<\/p>\n<p> udf_open_lvid+0x369\/0x5b0 fs\/udf\/super.c:2078<br \/>\n udf_reconfigure+0x336\/0x540 fs\/udf\/super.c:679<br \/>\n reconfigure_super+0x232\/0x8f0 fs\/super.c:1080<br \/>\n vfs_cmd_reconfigure fs\/fsopen.c:268 [inline]<br \/>\n vfs_fsconfig_locked+0x171\/0x320 fs\/fsopen.c:297<br \/>\n __do_sys_fsconfig fs\/fsopen.c:463 [inline]<br \/>\n __se_sys_fsconfig+0x6b9\/0x810 fs\/fsopen.c:350<br \/>\n do_syscall_64+0x174\/0x580 arch\/x86\/entry\/syscall_64.c:94<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>udf: Mark LVID buffer as uptodate before marking it dirty<\/p>\n<p>When an I\/O error occurs while writing the Logical Volume Integrity<br \/>\nDesc<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25997","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25997","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25997"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25997"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25997"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}