{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89894 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89894 is a high-severity memory corruption vulnerability in Linux, published on 16 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-89894 and fix it if it is affected.\n\nWhat it is: CVE-2026-89894 is a high-severity memory corruption vulnerability in Linux, published on 16 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-89894 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-89894/ (Markdown: https://insights.sbomify.com/CVE-2026-89894/index.md)","id":"CVE-2026-89894","markdown":"https://insights.sbomify.com/CVE-2026-89894/index.md","name":"CVE-2026-89894","record":{"aliases":["AZL-101478","BELL-CVE-2026-89894","DEBIAN-CVE-2026-89894","GHSA-c3cf-vcgj-vrgp","UBUNTU-CVE-2026-89894"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"low_privilege","summary":"A local attacker can trigger a heap out-of-bounds write in the cx231xx VBI driver by changing video geometry while the VBI queue is active, potentially leading to code execution.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: reject geometry changes while the VBI queue is busy\n\nvidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide\ndev-\u003ewidth / dev-\u003enorm but only refuse the change when the *video* queue\n(dev-\u003evidq) is busy. The VBI queue (dev-\u003evbiq) shares that same geometry:\ncx231xx_init_vbi_isoc() latches dma_q-\u003elines_per_field from dev-\u003enorm,\nthe VBI videobuf2 plane is sized from dev-\u003ewidth / dev-\u003enorm in\nvbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then\nrecomputes the destination offset from the *live* dev-\u003ewidth and the\nlatched lines_per_field on every URB completion:\n\n\toffset = lines_completed * (dev-\u003ewidth \u003c\u003c 1) + ...;\n\tif (dma_q-\u003ecurrent_field == 2)\n\t\toffset += dev-\u003ewidth * 2 * dma_q-\u003elines_per_field;\n\tmemcpy(plane + offset, p_buffer, lencopy);\n\nBecause the VBI node shares video_ioctl_ops with the video node, an\napplication can size a small VBI plane (REQBUFS/QBUF with a small width,\nor with the NTSC standard), then enlarge dev-\u003ewidth (or switch dev-\u003enorm\nto PAL) through the video node while the VBI stream is running -- the\nchange is allowed because only dev-\u003evidq is checked -- and let the device\ndeliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the\noffset with the larger geometry and memcpy()s past the end of the smaller\nplane that was already allocated, a heap out-of-bounds write whose offset\nis attacker-chosen and whose contents come from the device. The\nper-field guard in cx231xx_copy_vbi_line() does not help: it bounds the\ncopy against the latched lines_per_field, not the plane's real capacity,\nand vb2 does not re-run buf_prepare() for an already prepared buffer.\n\nRefuse the format/standard change when the VBI queue is busy as well, so\nthe geometry cannot change underneath an allocated VBI buffer.","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":"media: cx231xx: reject geometry changes while the VBI queue is busy","id":"CVE-2026-89894","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"media: cobalt: Avoid freeing ALSA private data twice","id":"CVE-2026-89895"},"packages":[],"prev":{"headline":"media: cx23885: cancel NetUP CI work before teardown","id":"CVE-2026-89893"},"products":["Linux"],"published":"2026-09-16","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker can trigger a heap out-of-bounds write in the cx231xx VBI driver by changing video geometry while the VBI queue is active, potentially leading to code execution.","url":"https://insights.sbomify.com/CVE-2026-89894/"}