The buffers array was sized min(count, DRI2BufferHiz) + 1, but count is
already capped at DRI2BufferHiz + 1 by the check above. The min() only
changes anything at that exact boundary (count == DRI2BufferHiz + 1), where
it throws away the array's '+1 slack' right when the main loop can
legitimately fill all 'count' slots itself, leaving no room for a
synthesized real/fake front buffer the client didn't explicitly request.
Trigger: a DRI2-capable client sends DRI2GetBuffers/DRI2GetBuffersWithFormat
with 11 attachment entries (the maximum allowed), none of them
DRI2BufferFrontLeft but at least one DRI2BufferBackLeft (so need_real_front
ends up set) -- the post-loop synthesis writes buffers[11], one past the
11-element allocation. Deterministic, no OOM required.
Fix: allocate count + 1 slots unconditionally; count is already bounded, so
this is never a meaningfully larger allocation.
Found via a fleet-directed alloc-fail/UAF sweep of Xext/, not from a live
crash report.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
c03bc789ae