{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98919 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-98919 is a vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-98919 and fix it if it is affected.\n\nWhat it is: CVE-2026-98919 is a vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-98919 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-98919/ (Markdown: https://insights.sbomify.com/CVE-2026-98919/index.md)","id":"CVE-2026-98919","markdown":"https://insights.sbomify.com/CVE-2026-98919/index.md","name":"CVE-2026-98919","record":{"aliases":["BELL-CVE-2026-98919","DEBIAN-CVE-2026-98919","GHSA-wghv-7vwx-fc47","UBUNTU-CVE-2026-98919"],"analysis":null,"analysis_generated_by":null,"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\ndrm/xe: harden adjust_idledly() against divide-by-zero and overflow\n\nadjust_idledly() has several corner-case issues flagged during review:\n\n  1. If xe_gt_clock_init() failed to recognise the crystal clock,\n     gt-\u003einfo.timestamp_base is 0, which makes idledly_units_ps also 0.\n     The subsequent DIV_ROUND_CLOSEST(..., idledly_units_ps) is then a\n     divide-by-zero and panics the kernel.\n\n  2. The tick-to-ns conversions are done in u32:\n        idledly * idledly_units_ps, (maxcnt - 1) * 1000\n     Both overflow u32 before DIV_ROUND_CLOSEST() sees them.\n\n  3. If IDLE_WAIT_TIME reads back as 0, maxcnt evaluates to 0 and\n     the maxcnt - 1 clamp wraps to 0xFFFFFFFF in u32.\n\n  4. The register only stores whole ticks, so the clamped ns value has\n     to be converted to ticks and back. DIV_ROUND_CLOSEST() can round\n     that conversion up past maxcnt:\n\n       maxcnt = 640 ns, one tick = 666664 ps\n\n       clamp:        maxcnt - 1        = 639 ns\n       ns -\u003e ticks:  639000 / 666664   = 0.958 -\u003e rounds to 1 tick\n       tick -\u003e ns:    1 * 666664 / 1000 = 667 ns\n\n     667 ns is programmed into RING_IDLEDLY, but 667 \u003e= maxcnt (640),\n     so xe_gt_WARN_ON() fires again on every subsequent init.\n\nReturn early if timestamp_base is 0 (the unknown-crystal path).\nDo the conversions in u64 via the *_ULL() helpers so they cannot wrap.\nClamp with a floor (DIV_ROUND_DOWN_ULL) so the programmed delay stays\nstrictly below maxcnt, and guard the maxcnt == 0 case with a zero delay\nwhile still writing RING_IDLEDLY so INHIBIT_SWITCH_UNTIL_PREEMPTED is\ncleared.\n\nv2: Drop the redundant warn on the timestamp_base == 0 path;\n    xe_gt_clock_init() already warns on an unrecognised crystal clock.\n    Keep the early return to avoid the divide-by-zero. - Vinay\n\nv3: Field-mask the RING_IDLEDLY write with REG_FIELD_PREP(IDLE_DELAY, ...)\n    instead of writing the raw tick count, which could clobber\n    INHIBIT_SWITCH_UNTIL_PREEMPTED and reserved bits. Split the\n    inhibit-switch clear from the maxcnt clamp so a set inhibit bit no\n    longer forces a needless delay overwrite when the delay itself is\n    already valid. Use gt_to_xe(gt) instead of gt_to_xe(hwe-\u003egt).\n\n(cherry picked from commit d864065ea25e9d12897c175de9176ce46677e176)","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":"drm/xe: harden adjust_idledly() against divide-by-zero and overflow","id":"CVE-2026-98919","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"netfs: Fix missing alloc tagging of direct mempool allocations","id":"CVE-2026-98920"},"packages":[],"prev":{"headline":"mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()","id":"CVE-2026-98918"},"products":["Linux"],"published":"2026-10-23","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-23","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-98919/"}