{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-80701 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-80701 is a vulnerability in Linux, published on 28 Aug 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-80701 and fix it if it is affected.\n\nWhat it is: CVE-2026-80701 is a vulnerability in Linux, published on 28 Aug 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-80701 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-80701/ (Markdown: https://insights.sbomify.com/CVE-2026-80701/index.md)","id":"CVE-2026-80701","markdown":"https://insights.sbomify.com/CVE-2026-80701/index.md","name":"CVE-2026-80701","record":{"aliases":["BELL-CVE-2026-80701","DEBIAN-CVE-2026-80701","GHSA-xr66-5v48-7crq","UBUNTU-CVE-2026-80701"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"low_privilege","summary":"A local attacker with DRM master access can trigger a kernel null pointer dereference and system crash by requesting oversized cursors in the vmwgfx driver.","user_interaction":"not_required","vuln_class":"null_dereference"},"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\ndrm/vmwgfx: enforce cursor size limits for MOB cursors\n\nvmw_cursor_plane_atomic_check() bounds cursor width and height only\non the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the\ndefault on modern hosts -- accepts any size.  When the requested size\nexceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE,\nvmw_cursor_mob_get() returns -EINVAL and leaves vps-\u003ecursor.mob NULL.\nIts return value is then discarded in vmw_cursor_plane_prepare_fb(),\nso the subsequent vmw_cursor_update_mob() calls\nvmw_bo_map_and_cache(NULL) and oopses inside\nvmw_bo_map_and_cache_size() on the tbo.base.size load.\n\nReachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a\nsufficiently large width or height (e.g. cursor_max_dim + 1).\n\nReject oversized cursors in atomic_check for both MOB-backed cursor\nupdate types.  The MOB byte-size limit only applies to the\nSVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for\nGB_ONLY); compute the required MOB size in 64-bit to avoid overflow\nwhen very large dimensions are requested.\n\nIn prepare_fb only call vmw_cursor_mob_get()/_map() for\nVMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo-\u003emap.virtual\ndirectly and would otherwise be silently downgraded to NONE on hosts\nwithout SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always\nreturns -EINVAL).  Degrade the update to NONE if vmw_cursor_mob_get()\nor vmw_cursor_mob_map() fails so the update path does not run with a\nNULL backing MOB.","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/vmwgfx: enforce cursor size limits for MOB cursors","id":"CVE-2026-80701","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"null_dereference","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size","id":"CVE-2026-80702"},"packages":[],"prev":{"headline":"drm/vmwgfx: validate external BO copy bounds for both stride paths","id":"CVE-2026-80700"},"products":["Linux"],"published":"2026-08-28","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-08-28","vendors":["Linux"]},"summary":"A local attacker with DRM master access can trigger a kernel null pointer dereference and system crash by requesting oversized cursors in the vmwgfx driver.","url":"https://insights.sbomify.com/CVE-2026-80701/"}