The three NV12/P010 pack functions (pack_nv12_single_to_plane,
pack_nv12_to_planes, pack_p010_to_plane) wrote into the V4L2
client's CAPTURE dmabuf without checking that the mapped size
covers the frame libavcodec just decoded.
Crash scenario: YouTube DASH stepping resolution mid-stream
(e.g. 480p -> 720p when bandwidth improves) — libva is supposed
to handle the V4L2_EVENT_SOURCE_CHANGE with STREAMOFF / S_FMT /
REQBUFS, but in practice a stale CAPTURE request with the old
buffer size sometimes slips through carrying the new (larger)
frame. The chroma-interleave inner loop walks past the mapping
boundary and the daemon takes SIGSEGV mid-frame, which in turn
leaves V4L2 clients hanging in vb2_core_dqbuf — see the followup
ticket on the D-state symptom.
Fix: compute required = y_size + uv_size against planes->size[N]
BEFORE any write. On mismatch, log_warn with both sizes and the
frame dimensions, and return -EOVERFLOW.
The caller (process_decode_request loop) already handles a
negative pack return with a log_warn and proceeds without
aborting the decode — the kernel still gets the response with
metadata-only and the V4L2 client sees a frame whose pixels are
stale but whose buffer-done event fires normally. The next
SOURCE_CHANGE the client processes resyncs the buffer size.
All three pack paths get the same bounds-check; the comment on
pack_nv12_single is the canonical explanation, the other two
reference it.
Verified: builds clean against trixie aarch64; no behavioural
change on the happy path (the bounds check is a single size
compare; on a correctly-sized CAPTURE buffer it's a 1-cycle pass).
Closes daedalus-v4l2 task #145 (daemon SEGV in pack_nv12_single
on resolution change).
claude-noether