Cloudanix VulnDB

CVE-2026-93140

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A Linux kernel bug can produce confusing warning messages after certain disk-write problems on UDF-formatted drives, but it does not allow outsiders to steal or change data.

Exploitation
Other
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

In the Linux kernel UDF driver, an I/O error on LVID buffer write clears BH_Uptodate; subsequent calls to udf_open_lvid or udf_sync_fs then call mark_buffer_dirty on a buffer whose flag is not set, triggering WARN_ON_ONCE(!buffer_uptodate(bh)).

Why it matters to the business

Kernel log spam and potential masking of genuine errors on systems using UDF volumes; low operational risk but may trigger unnecessary alerts or complicate troubleshooting after transient block-device failures.

How an attack unfolds

An adversary or automated process induces a write error to the LVID buffer (for example via faulty storage), then performs a read-write remount or filesystem sync; the driver path then hits the warning condition without any further attacker-controlled data manipulation.

How to fix it

Apply the upstream fix that unconditionally sets BH_Uptodate before mark_buffer_dirty in udf_open_lvid and udf_sync_fs (extending the earlier change in udf_close_lvid). Rebuild or install the corrected kernel and reboot affected systems.

How to confirm the fix worked

After patching, reproduce the I/O-error-plus-remount sequence and confirm the warning no longer appears; inspect fs/udf/super.c for the uptodate assignment and verify the buffer.c WARN site is not reached.

Typical attack path

  1. Cause or wait for an I/O error while writing the LVID buffer
  2. Trigger remount read-write or explicit sync on the UDF filesystem
  3. Observe the buffer.c WARN_ON_ONCE in kernel logs

How to detect it

Search kernel logs (dmesg, journalctl, /var/log/kern.log) for the exact warning text originating from mark_buffer_dirty together with call traces containing udf_open_lvid or udf_sync_fs; correlate with prior block-layer I/O error messages on the same device.

  • !buffer_uptodate(bh)
  • udf_open_lvid
  • udf_sync_fs
  • WARNING: fs/buffer.c

What your security team should do

  • Include the corrected kernel in the next patch cycle for any systems mounting UDF volumes
  • Add the string '!buffer_uptodate(bh)' to log-monitoring rules to surface occurrences until patches are deployed
  • Review storage health on hosts that log the warning to rule out underlying hardware faults

The record

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>

Affected packages

Ecosystem Package Introduced Fixed