{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-93140 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-93140 is a denial of service vulnerability in Linux, published on 17 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-93140 and fix it if it is affected.\n\nWhat it is: CVE-2026-93140 is a denial of service vulnerability in Linux, published on 17 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-93140 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-93140/ (Markdown: https://insights.sbomify.com/CVE-2026-93140/index.md)","id":"CVE-2026-93140","markdown":"https://insights.sbomify.com/CVE-2026-93140/index.md","name":"CVE-2026-93140","record":{"aliases":["AZL-102945","BELL-CVE-2026-93140","DEBIAN-CVE-2026-93140","GHSA-hwwj-mw3q-359r","UBUNTU-CVE-2026-93140"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel UDF","requires_auth":"low_privilege","summary":"A local attacker can trigger a kernel warning and potential instability by remounting a UDF filesystem after an I/O error.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Mark LVID buffer as uptodate before marking it dirty\n\nWhen an I/O error occurs while writing the Logical Volume Integrity\nDescriptor (LVID) buffer to the block device, the block layer's completion\nhandler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the\nbuffer. However, the buffer still contains valid LVID data in memory. If\nthe filesystem is subsequently remounted read-write or synced,\n`udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call\n`mark_buffer_dirty()`. This triggers a spurious\n`WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()`\nbecause the buffer is not marked uptodate, even though its in-memory\ncontents are valid and are about to be overwritten.\n\nTo prevent this spurious warning, unconditionally set the `BH_Uptodate`\nflag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and\n`udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and\nmatches the workaround previously applied to `udf_close_lvid()` in commit\n853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\").\nExtending this workaround ensures consistent behavior across all LVID\nupdates.\n\nBuffer I/O error on dev loop0, logical block 128, lost sync page write\n------------[ cut here ]------------\n!buffer_uptodate(bh)\nWARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087\n...\nCall Trace:\n \u003cTASK\u003e\n udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078\n udf_reconfigure+0x336/0x540 fs/udf/super.c:679\n reconfigure_super+0x232/0x8f0 fs/super.c:1080\n vfs_cmd_reconfigure fs/fsopen.c:268 [inline]\n vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297\n __do_sys_fsconfig fs/fsopen.c:463 [inline]\n __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350\n do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94\n \u003c/TASK\u003e","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"udf: Mark LVID buffer as uptodate before marking it dirty","id":"CVE-2026-93140","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"usb: gadget: r8a66597: avoid double free of ep0_req in probe error path","id":"CVE-2026-93141"},"packages":[],"prev":{"headline":"drm/amdgpu/mes: Fix hung_queue_db_array loop limit for multi-XCC","id":"CVE-2026-93139"},"products":["Linux"],"published":"2026-09-17","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker can trigger a kernel warning and potential instability by remounting a UDF filesystem after an I/O error.","url":"https://insights.sbomify.com/CVE-2026-93140/"}