{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-74453 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-74453 is a high-severity vulnerability in Linux, published on 15 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-74453 and fix it if it is affected.\n\nWhat it is: CVE-2026-74453 is a high-severity vulnerability in Linux, published on 15 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-74453 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-74453/ (Markdown: https://insights.sbomify.com/CVE-2026-74453/index.md)","id":"CVE-2026-74453","markdown":"https://insights.sbomify.com/CVE-2026-74453/index.md","name":"CVE-2026-74453","record":{"aliases":["AZL-95991","BELL-CVE-2026-74453","DEBIAN-CVE-2026-74453","GHSA-3p68-w4fc-v365","UBUNTU-CVE-2026-74453"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read","denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel DRM","requires_auth":"low_privilege","summary":"Attackers can read stale GPU memory or cause hangs because the kernel fails to clear tile state data between jobs.","user_interaction":"not_required","vuln_class":"information_disclosure"},"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\ndrm/vc4: Zero the tile state data array before each BIN job\n\nThe binner BO is a single 16MB buffer split into 512KB slots that are\nhanded out to jobs at submission time and recycled as jobs complete,\nwithout ever being cleared. Each slot holds the job's Tile State Data\nArray (TSDA) at its start, followed by the tile allocation pool.\n\nWhile the tile allocation pool is only walked by the render thread\nthrough branches the binner generated during the current job, the\nTSDA is the PTB's own per-tile bookkeeping and is consumed by the\nhardware itself. Although the kernel sets the \"Auto-initialise Tile\nState Data Array\" flag in the tile binning mode configuration, the\nPTB demonstrably still acts on stale tile state left by the slot's\nprevious user: the binner ends up creating invalid command streams\nwith invalid primitive streams and branches, which can cause GPU hangs\nas observed in [1][2].\n\nZero the TSDA when the job's binning slot is configured. This clears\n48 bytes per tile (~24KB for a 1080p frame) in the submission path, and\nguarantees the PTB never sees another job's tile state.\n\nThe tile count is only checked for being non-zero today, so the 8-bit\nfields it comes from can describe a tile state array almost six times\nlarger than the slot it has to live in. Bound it before the slot is\nhanded out, since such size decides how much of the slot is left for\nthe tile alloc pool.","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/vc4: Zero the tile state data array before each BIN job","id":"CVE-2026-74453","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"information_disclosure","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size","id":"CVE-2026-74454"},"packages":[],"prev":{"headline":"drm/panthor: reject firmware sections with oversized data","id":"CVE-2026-74452"},"products":["Linux"],"published":"2026-08-15","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":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-10-16","vendors":["Linux"]},"summary":"Attackers can read stale GPU memory or cause hangs because the kernel fails to clear tile state data between jobs.","url":"https://insights.sbomify.com/CVE-2026-74453/"}