{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89490 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89490 is a vulnerability in Linux, published on 11 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-89490 and fix it if it is affected.\n\nWhat it is: CVE-2026-89490 is a vulnerability in Linux, published on 11 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-89490 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-89490/ (Markdown: https://insights.sbomify.com/CVE-2026-89490/index.md)","id":"CVE-2026-89490","markdown":"https://insights.sbomify.com/CVE-2026-89490/index.md","name":"CVE-2026-89490","record":{"aliases":["AZL-100220","BELL-CVE-2026-89490","DEBIAN-CVE-2026-89490","GHSA-3jg7-r7pg-8654","UBUNTU-CVE-2026-89490"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A 32-bit integer overflow in the OCFS2 filesystem causes infinite loops during directory enumeration on large files, leading to denial of service.","user_interaction":"not_required","vuln_class":"integer_overflow"},"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\nocfs2: fix readdir position truncation on 32-bit kernels\n\nIn ocfs2_dir_foreach_blk_el(), the directory cookie position is\nrebuilt with\n\n\tctx-\u003epos = (ctx-\u003epos \u0026 ~(sb-\u003es_blocksize - 1)) | offset;\n\n`ctx-\u003epos` is loff_t (signed 64-bit), while `sb-\u003es_blocksize` is\nunsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask\n\n\t~(sb-\u003es_blocksize - 1)\n\nis computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB\nblock size).  In the AND expression with the 64-bit `ctx-\u003epos`, that\nunsigned operand is zero-extended to 64 bits per the usual arithmetic\nconversions, yielding 0x00000000fffff000.  The high 32 bits of\n`ctx-\u003epos` are silently cleared, even though directory size is\nallowed to exceed 4 GiB.\n\nWhen readdir() crosses the 4 GiB boundary on a 32-bit kernel the\nposition is reset back into the first 4 GiB block, making the\nre-validation path re-enumerate already-returned dirents indefinitely.\n\nThis is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken\nfor all non-inline directories, so a directory large enough to cross\n4 GiB reaches it.\n\nThis is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix\nbitwise operation having different size\") fixed in exfat, and the\nfix mirrors the equivalent ext4 fix in this series.  Cast the operand\nto loff_t so the mask is 64-bit before the AND:\n\n\tctx-\u003epos = (ctx-\u003epos \u0026 ~((loff_t)sb-\u003es_blocksize - 1)) | offset;\n\n64-bit kernels are unaffected.","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":"ocfs2: fix readdir position truncation on 32-bit kernels","id":"CVE-2026-89490","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"integer_overflow","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin()","id":"CVE-2026-89491"},"packages":[],"prev":{"headline":"openrisc: fix arbitrary kernel memory access via or1k_atomic syscall","id":"CVE-2026-89489"},"products":["Linux"],"published":"2026-09-11","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 32-bit integer overflow in the OCFS2 filesystem causes infinite loops during directory enumeration on large files, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2026-89490/"}