Description

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the "Auto-initialise Tile State Data Array" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:49.893Z",
  "pubdate": "2026-08-15T13:17:49.893Z",
  "executiveSummary": "A vulnerability has been identified in the Linux kernel within the drm/vc4 driver component, specifically related to the management of the binner buffer object (BO) tile state data array (TSDA). The vulnerability arises because the driver reuses 512KB slots from a 16MB binner buffer across multiple submission jobs without properly clearing or zeroing the TSDA and tile state data between allocations.\nAlthough the kernel enables the Auto-initialise Tile State Data Array flag, hardware execution demonstrates that the PTB still acts upon stale tile state data left behind by previous jobs. This flaw allows residual tile states to influence subsequent executions, leading to invalid command streams, invalid primitive streams, and erroneous branches.\nThe primary impact of this vulnerability is a denial of service via GPU hangs. Affected systems include those utilizing the Broadcom VC4 graphics driver in the Linux kernel. The exploitation requires local execution capabilities to submit jobs to the GPU driver, potentially causing system-wide graphical freezes or instability when conflicting job submissions process stale memory residues.",
  "technicalDetails": "The vulnerable component is the drm/vc4 graphics driver in the Linux kernel, specifically within the job submission and memory management paths handling the binner buffer object (BO). The binner BO consists of a single 16MB buffer divided into 512KB slots that are dynamically allocated to jobs upon submission and recycled upon completion.\nEach 512KB slot begins with the Tile State Data Array (TSDA), followed immediately by the tile allocation pool. While the tile allocation pool is traversed solely by the render thread via branches generated by the binner during the active job, the TSDA serves as the PTB's per-tile bookkeeping data structure and is consumed directly by the hardware.\nThe root cause of the vulnerability is the absence of memory sanitization prior to assigning a binner slot to a new job. Because slots are recycled without being cleared, residual TSDA data from prior workloads persists. Despite the hardware configuration setting the Auto-initialise Tile State Data Array flag, the PTB continues to process stale tile state data from the slot's previous user.\nThis behavior causes the binner to generate malformed command streams containing invalid primitive streams and incorrect branches. Consequently, the GPU encounters inconsistent execution states, resulting in severe hardware hangs as observed in typical runtime environments. Furthermore, an auxiliary issue existed where the tile count was validated only against non-zero values, allowing 8-bit fields to describe a tile state array significantly larger than the physical slot containing it, potentially spilling over into the tile allocation pool.\nStep-by-step, exploitation or accidental triggering occurs as follows: (1) An initial GPU job executes and populates a 512KB binner slot with custom TSDA and tile allocation data. (2) The job completes, and the slot is returned to the recycling pool without being zeroed out. (3) A subsequent, unrelated job is submitted and is assigned the same recycled 512KB slot. (4) The PTB reads the uninitialized or stale TSDA data remaining from the first job instead of relying solely on fresh initialization. (5) The hardware processes the contradictory state, generates invalid command and primitive streams, and triggers a GPU hang."
}