| Age | Commit message (Collapse) | Author | Files | Lines |
|
The dimension cap closed the named overflow, but stride was still
r.RowStride whenever RowStride >= Width*Channels, and asInt accepts an
int64 wire value. With Width=2, Height=2, RowStride=MaxInt the int64
need product wraps negative, the guard passes, and r.Data[y*stride:]
panics at y=1. Reject a negative stride and any stride above
Width*Channels+4096, which is the real packing plus alignment slack.
After the cap and this bound neither need nor y*stride can overflow, so
the comment now says so.
|
|
A notification is untrusted input. RawImage.PNG computed
stride*(Height-1)+Width*Channels in int, so Width=Height=2^31-1 with
RowStride=0 wrapped the length expression negative, slipped past the
guard, and reached image.NewRGBA, which panics. The D-Bus call path has
no recover, so one malformed Notify killed the daemon. Cap Width/Height
at 1<<16 before any multiplication and compute the required byte count
in int64.
image-data, image-path and the deprecated icon_data were read as one
tier, with icon_data ahead of image-path, inverting the spec's order.
Split the deprecated key into IconDataFromHints and apply tier 1
(image-data/image_data), then image-path, then icon_data. Raw handling
is unchanged: encode, hold pendingImage, WriteImage after Add, SetImage.
|
|
image-data (and the deprecated icon_data) is the (iiibiiay) struct; the
PNG encoder honours rowstride and both 3- and 4-channel data. The path
and data readers are pure, so the service can apply the spec's priority
and the store stays free of image handling.
|